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NAMING AND PROTECTION IN EXTENDIBLE OPERATING SYSTEMS 

David Day Redell 

Abstract 

The properties of capability-base4 extendible operating systems 
are described, and various aspects of such systems are discussed, 
with emphasis on the conflict between free di&trlbut*pn of access 
privileges and later revocation of those privileges. The discussion 
culminates in a set of goals for a new capability scheme. 

A new design is then proposed, which provides both type exten- 
slon and revocation through the definition of generaH«ed sealing 
of capabilities. The implementation of this design is discussed 
in sufficient detail to demonstrate that it would be workable and 
acceptably economical. 

The utility of the proposed capability mechanism is demon- 
strated by describing two facilities implementable in terms of it. 
These are: (a) revocable parameters for calls between mutually 
suspicious subsystems, and (b) directories providing a civilized 
medium for the storage and distribution of revocable capabilities. 
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Chapter 1 
Introduction 



l.'l Overview 



Computers have "been with us noW for just over a quarter of a 
century. Although their ultimate potential impact oh society is 
still hard to predict, it seems safe to say that they will rank 
with such transforming inventions as the prilling press and tele- 
vision in their effect not only On the way we live, hut also on 
the way we think. Already their role has shifted from that of 
simply high speed calculating toolis to a more fundamental function 
as the natural repository for an increasing amount of society's 
body of information, the near future should' sfee the development 
of computer utilities bringing reliable and ecbnowiclal computer 
access to the general public, in the form of services of unpre- 
cedented scope and power [Fr 74]. 

These new roles of computers raise many serious social ques- 
tions which are far from being answered [Ro 74, DF 65, HEW 73]. 
Moreover, even if these questions are satisfactorily answered, the 
resulting policies will require an appropriate technological frame- 
work within which they can be expressed and enforced [Po 74, Pe 74], 
Thus, such social and legal issues as privacy, secrecy, confiden- 
tiality, and accountability generate a technological problem which 
could be called the "total system security problem." 

The main subject of this thesis Is protection . Protection is 
that aspect of the total system security problem which deals with 
the control of access by programs running within a computer system 
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to information stored within the system [%a 71, Jo 73]. It is thus 
concerned with prevention of undesived accesses, whether accidental 
or malicious. Protection is intimately involved with the naming 
mechanisms used by programs to specify whlc^ items of information 
they wish to access. . We will discuss system designs which provide 
both naming and protection in a single Integrated mechanism [DVH 66, 
Fa 74]. We also emphasize the notion of freely distributable 
access privileges, in the sense that any possessor of a privilege 
may pass it on as he sees fit (1a 69 J , <3m the other hand, we recog- 
nize the Importance of allowing .later j&qotpj^jgtk. -«g such privileges. 
The main result of the thesis is the description of a naming and 
protection mechanism allowing botfc %** 4fyf*p£3t0ytfm of privileges 
and subsequent revocation in an ojrdpjcly $f*y^ < L , 

Another desirable characteristic of naming and protection 
mechanisms is extendlbility [La 6th,, ^JMl^^ TJ^.pi?o^rty allows 
the construction of the system if* , ,|jiyerji ; of -^JUsmji^S} of abstraction" 
{Di 68b], thus increasing reliability and .aJULowiJigi user-written 
extensions to augment the system with new servlqes^ la a uniform 
way. The extendibllity of the propose^, aM^u^isma will be discussed 
in some detail. 



1.2 ProjectJLga 

The protect ion. problem is only one aspect of, jgie^ total system 

security problem. , Thus.,. in ^.emjajAns^ the g&ypxffe. tftabfafm* it 
is important to delimit the scope of the d|f|f5^i«n, i? b3r; r |liJ(|^uish- 
ing several other closely related problems, including: 
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a) hardware reliability 

b) Physical security 

c) User authentication 

4) Personnel certification 
All of the above problems exhibit two rathf r unfortunate properties: 

1) They do not admit of compete r eoluf4pna* bu£ ; on|,y of solu- 
ions quantitatively comparable in tfrspf pf cost^ffective 
prevention of trouble (e,g v hi£h penetration, cost , long 
mean-time-between-f allures, etc.) : . 

2) The failure of a splutioa t? any o|te of thew can under- 
mine the entire protection system. 

On the other hand, if we hypothesize a situation .Ja ^ which problems 
(a) through (d) have been completely solved, we can consider the 
protection problem as occurring in a self-contained artificial 
universe , free of such real-world djJatra^fcJ^aBS; a^^cks which can 
be picked and circuits which can burn out. Within tbjis idealized 
framework the protection problem 4°^ *4msU .of complete solutions 
in many important situations [La.74|. Thi^ ia not to say, of 
course, that all solutions constructed within such a framework 
are automatically complete, fox example* on£ can protect 4eta by 
requiring accessing programs to provide ,,». paas»or4 on key authorizing 
the access [La 69 ] r Internal passwords, like external passwords , 
are vulnerable to guessing, and are t^us not a joim^te solution. 
On the other hand, one can Implement intenxal k^ya which are 
unforgeable, opening locks which are unpickah^B, thus providing 
a complete solution to the problem. The significance pf this lies 
not primarij-y in the reduction of the probability of failure (from 



negligible to zero) but in the conceptual shift in how one views 
the mechanism (with absolute confidence, rather than quantitative 
optimism). 

It can be argued that the above viewpoint is unrealistic, 
since problems (a) through (d) do not admit of complete solutions 
as hypothesised. The point, however, is that tffis f actor izat ion 
of the total security problem allows one to take a very rigorous 
approach to the situation in which malicious intent manifests 
itself in the behavior of high speed internal computations. This 
is precisely the situation in which our intuitions are least likely 
to prove reliable in assessing the quantitative adequacy of incom- 
plete solutions. 



1.3 Framework for Discussion 

For our purposes, we can regard the function of the operating 
system as being the transformation of the basic hardware resources 
of the computer into a universe of abstract resources or objects , 
and a set of operations for manipulating those objects. This point 
of view is often referred to as the object -or ten ted approach, and 
the collection of operations as the abstract machine . Eaclh object 
has an attribute called its type , which determines the set of 
operations which can meaningfully be applied to fch*f object. Various 
types of objects are provided, most notably processes . Processes 
are the active entities in the system, capturing the intuitive 
notion of a "locus of control" or "execution point." Processes 
can attempt to access other objects in the system by performing 
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various operations on them, and it is these accesses which are 
checked and allowed or disallowed by the protection mechanisms of 
the system. At any given time, a process has some set of privileges , 
specifying which operations it may perform on which objects, this 
set of privileges is called the domain in which the process is 
executing. The privileges available to a process can change as a 
result of either: 

a) addition or removal of privileges in its domain of 
execution, or 

b) switching to a different domain of execution. 

Thus, domains themselves have an independent existence and are 
objects in their own right. (The reasons, for taking tbfs point of 
view will become^ clear in Chapter 2.| A domain can be characterized 
as a passive object, serving to control the execution of an active 
process. It will often be convenient, however, to refer to the 
actions of a process executing in a domain as being performed by 
the domain itself, and we will use this active characterization 
when there is no danger of ambiguity. 

The domain model is general enough to describe m?st protection 
schemes found in existing systems [La 71]. We are interested in 
a particular class of such schemes in which a domain consists of 
a set of capabilities [DVH 6^, La 69 f Fa 74}. A capability serves 
both as the name of an object and as a set of privileges to access 
that object. Thus, in a capability system, a domain is able to 
name only those objects to which it has access via, its capabilities. 
Those capabilities are stored in the memory of the domain, which 
we will assume consists of a number of seg m ents [De 65, BCD 72], 



each of which comprises a variable length array of addressable 
items. A domain may copy its capabilities and distribute them as 
it sees fit, although it may not, of course, make arbitrary modi- 
fications to them. Thus, capabilities are like data "sealed in a 
box," a characterization which we will pursue in some detail later. 



1.4 The Computer Utility 

The mechanisms discussed in this thesis would be useful in 
any computer system. The context which maximizes their importance, 
however, is that of the computer utility. The notion of a computer 
utility has received considerable attention in the literature fCV 65, 
Sa 66, Sc 72, Fr 74] and seems likely to play an Increasingly 
important role in the future, in. such a utility, a large user 
community shares an appropriately large information storage and 
processing facility in much the same manner that the users of elec- 
trical and telephone utilities share the corresponding power genera- 
tion and communication facilities. Such physica l sharing (i.e.*, 
sharing of physical resources) provided the original motive for. 
developing multi-user computer systems. That motive was the desire 
to lower the cost of hardware resources through economies of scale 
and statistical smoothing of load fluctuations. This is gradually 
being rendered less important by the continual decline in hardware 
costs. A much more fundamental motive remains, fcowfever, which is 
in itself more than adequate justification for building a computer 
utility. This is the desire for flexible logical sharing (sharing 
of information) between users, so that they may build upon each 
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other's work [Sa 66, De 68]. 

Since the user community of a computer u^^^t^ .po^s^s.ts of the 
public at large, the logical sharing within that community takes 
on more the character of transactions In a marketplace than of 
informal friendly cooperation [Fr 74]. In particular; 

a) Sharing is Often financially motivated. 

b) The parties involved may not trust each other. 

Point (a) implies that sharing of ten represents sale or rental of 
the shared objects. The rental case is , a,, strong test of the pro- 
tection and accounting mechanism of the computer, utility. This is 
particularly true in the case of subletting, in. which access to a 
rented object passes through several hands before reaching the end 
user. Point (b) , which is in part a .result ,f^ fi |a) , ref lects the 
fact that the standard attitude of the parties involved in a trans- 
action in any market place is usually some degree of mutual suspi- 
cion. Since programs in the system serve af the agfnts of users 
on the outside, the programs themselves also exhibit mutual suspi- 
cion. More detailed discussion and examples of mutual, suspicion 
can be found in Lampson [La 691 and Schroeder [Sc 72]. 

One aspect of the mutual suspicion problem which can be awk- 
ward to handle is the fact that the degree of suspicion between two 
users may change with time. For example, _ an j>: em»j|ovee may Join or 
leave a company, or a renter may be late in paying his bill. Thus, 
it is important that the privileges of a given user, or program to 
access a given object be able to change with, time. Moreover, it 
is very desirable that these adjustments of privileges be a,s pain- 
less as possible. We will address this issue^ ,at > some length, 



particularly In the case of Increasing suspicion where previously 
granted privileges are to be revoked. 



1*5 Extendlfallity 

The construction of a large operating system is a formidable 
task. As the richness of the user environment provided is increased, 
so also is the else and complexity of the system which provides it . 
In fact, unless controlled by a suitable design methodology, the 
complexity of a large operating system may preclude its ever being 
completely debugged. One of the most promising such methodologies 
is that 6f layering , in which the systea is constructed as a base- 
level* and a series of extensions . Each layer extends the environ- 
ment in which it runs, thus presenting a richer environment for 
higher layers. The key assumption in such a system is that no layer 
has embedded in it any knowledge of the functioning of higher 
layers. This, combined with the obvious precaution of protecting 
lower layers from toferference by higher layers, yields a structure 
in which changes to and malfunctions of higher layers cannot affect 
the correct functioning of lower layers in any way. 

The construction of a layered system can be viewed to two ways. 
From a top-down point of view* the task is one of appropriately 
dividing the desired set of functions into a sequence of layers. 

f 

From a bottom-up point of view, the task is to transform some pre- 
exist tog system into a more complete environment by adding useful 
new features. The latter point of view is most appropriate to the 
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*Sometimes called the "kernel" tWu 74] or "nucleus" [Ha^O]. 
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case of user-written extensions, although to a large extent, the 
exact distinction between system programs and user programs becomes 
unimportant in a layered design. 

Given the object-oriented point of view discussed above, the 
appropriate way to view extensions is as defining new types of 
objects and providing the appropriate operations on them. This 
immediately raises the question of how such objects are .named and 
how access to them is controlled. It is nost desirable for the base- 
level naming and protection mechanisms to provide these functions 
for all higher level objects in the system. We will describe 
various type extension features which allow this. 



1.6 Thesis Plan 

Since the mechanisms described in this thesis represent fur- 
ther developments of ideas found in several existing or proposed 
computer systems, it Is appropriate to summarize those ideas. 
Therefore, Chapter 2 begins by describing a hypothetical system 
exemplifying the relevant features of those systems, and goes on 
to discuss the use of those features In various situations, placing 
special emphasis on revocation of privileges and on type extension. 
The chapter concludes with a list of goals derived from these 
discussions . 

The central portion of the thesis is Chapter 3, which proposes 
a new system design satisfying the goals derived in Chapter 2, and 
discusses the implementation of that design in some detail. Some 
possibilities for further elaboration of the design are also 
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discussed briefly. 

Chapter 4 examines the use of the mechanisms of Chapter 3 in 
providing two facilities helpful in common situations: revocable 
parameters for mutually suspicious subsystem calls, and directories, 
for storage and distribution of capabilities. 

Finally, Chapter 5 summarizes the results of the thesis and 
briefly evaluates their significance. 
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Chapter 2 
A Typical CaaaMliliy Sswtem 

2.1 A Typical Capability System 

The central goal of this thesis Is the detailed specification 
of a proposed behavior for capabilities, and the description of an 
efficient implementation of capabilities exhibiting such behavior. 
The main aspects of capability behavior to be examined are the 
distribution and revocation of privileges, and type extension. To 
bring the issues into focus, we sketch a hypothetical system called 
"TCS" (for "Typical Capability System") to serve as a context for 
discussion and as a starting point from which various improvements 
can be explored. This typical system as described below is not 
identical to any existing or proposed system but contains features 
found in many previous systems, including CALr-TSS {La 69, St 73], 
Magnum [Fa 68], Plessy 250 [En 72, Co 72], HYDRA [Jo 73, Wu 74], 
Project SUE [Gr 71], BCC 500 [La 69], and Multics [BCD 72, CV 65, 
Sa 74]. 

In the definition of TCS, two conflicting considerations 
influence the level of detail at which the various features should 
be described. On the one hand, it is important that the definition 
be specific enough to make subsequent discussions clear and unam- 
biguous. On the other hand, the inclusion of extraneous detail 
would not only cloud the issue, but might also falsely appear to 
restrict the class of systems to which our subsequent improvements 
are applicable. 

For these reasons, the definition, that follows tends to pin 
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down only those details which are relevant to the later discussion. 
In other cases* several alternatives nay be sketched, or the fine 
points may be glossed over . entirely when not sufficiently 
interesting. 

In defining TCS, a logical place to begin is with the capa- 
bilities themselves. As stated previously, a capability serves 
both as the name of an object and as a package of privileges allow- 
ing the object to be accessed in various ways. It is also desirable 
to distinguish between objects of different types; in TCS this 
distinction is carried in the capability, rather than in the object 
itself, for reasons which will become clear during the discussion 
of type extension. Thus, a capability for an object contains: 

a) the unique identifier or "IB" of the object? 

b ) the typ e of the object, 

c) a set of privileges to access the object. 

Each domain in TCS has its own segmented address space . (As 
pointed out by Fabry [Pa 74}, freely copyable capabilities elimi- 
nate the need for communicating domains to share a common address 
space.) The capabilities possessed by a given domain are stored 
within the segments of its address space. At the same time, those 
capabilities serve as the skeleton which define* and structures 
that address space. (It is worth emphasizing that an address space 
defined by freely copyable capabilities tends to be a much more 
fluid structure than a more conventional address space defined by 
system data structures.) Associated with each domain is a single 



* 
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The object ID has sometimes been referred to mt the "unique name" 
or "global name" of the object. We wish -'to evoid this terminology 
to emphasize the fact that it is the capability itself which 
should be thought of as the global name of the object. 
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implicit segment , which serves as the "root" of its address space. 
A capability for the implicit segment is part of the definition of 
the domain. All other segments (or objects of other types) are 
addressed via capabilities in this Implicit segment. .There is no 
fundamental reason, however, to restrict capabilities to appear 
only in this implicit. segment; in fact, it will be assumed here 
that capabilities and "normal" data can be freely intermixed in 
any segment. (Ways of implementing this without compromising the 
integrity of the capabilities will be discussed later.) 

Outside the context of any particular address space, we can 
define the absolute address of an item (capability or datum) to be 
a pair <C,d>, where C is a capability (for * segment) and d 
is a displacement (word, byte, or bit number) . Let (C»d) denote 
the contents of address <C,d>. Then if 'C- is a. capability for 
some domain's Implicit segment, a simple address w issued by 
that domain corresponds to the absolute address <.C T »w?;. (i.e., 
word w of the implicit segment). Similarly, the standard notion 
of the two part address s|w of word w in segment s is equi- 
valent to <(C_,s),w>. When capabilities can be stored anywhere 
in the address space, addresses involving thep can become more com- 
plicated, such as sjwjjw- ?,<(£C I? s),v 1 );s r 2>; (where both *Cj.,s> 
and <(C_,s),w_>iMJSt contain seg«e|it capabilities^ > This suggests 
the provision of direct hardware implementation of these multi- 
level addresses and /or programmable capability rfgisters , to hold 

i l i ' " | / ' ' ■ il . i l i . ii i — ■^-^w. i 111 n m i i i . ii ' . 1 / 1 iiii i i . iii 

This is similar to the Unities deacrij it J B £| 723 or the 
CAL-TSS wdrfeing C-Ust IS* 73], In the 'lAOm. (fa 68] and 
Plessy 250 [En 72] machines, it is effectively implemented in hard- 
ware in the form of several capability registers. Lamps on [La 74] 
refers to the implicit segment as the "access point" of the domain. 
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intermediate capabilities during the evaluation of such addresses. 
Lacking these features, a domain could directly utilize only 
capabilities in its implicit segment; all other capabilities would 
have to be copied into the implicit segment before use. Various 
forms of multi-level addressing have been provided in existing 
systems [Ha 72, St 73, Se 72, Wu t4j. 

Figure 2.1-1 depicts two domains BL and D-, whose implicit 
segments are $ x and S 2 respectively, the address space of D. 
includes segments S ± , Sy S^ and Sy Hie address space of D, 
includes S 2 , S ± , By Sg, and $ y . 'tfoto "thai ' Sj and S 5 are 
shared by both domains, and that the eddress space of D. may in 
fact include (indirectly) the entire address space of &; depend- 
ing upon the privileges in D 2 's capability for S-. 

As mentioned in Chapter 1, domains can be characterised as 
either active or passive objects. In its passive role as a collec- 
tion of privileges, a domain in our typical capability system is 
Identical to its implicit segment; from this point of view, the 
distinction between a domain and a segment is simply a Question of 
emphasis. On the other hand, in Its active role as an exerciser 
of privileges, a domain is sure to require additional information 
in its representation, relating to control structures, error handling, 
entry points and so on, which we will call Its domain-descriptor . 
While the exact details of this extra information are not relevant 
to the current discussion, it will sometimes be useful to distin- 
guish between the domain in this larger sense, and its implicit 
segment. 
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Figure 2.1-1: An example of two domains 
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The active characterization of domains is somewhat imprecise, 
since, strictly speaking, nothing is ever done by a domain but 
always by a process executing in or associated with the domain. 
This raises the issue of the exact relationship between domains and 
processes. Since protection and scheduling are essentially inde- 
pendent functions, it is tempting to define domains and processes 
independently, and to allow processes (at least potentially) com- 
plete freedom to choose their domain of execution. This implies 
that . '::.:.. 

a) A given process may execute in various domains at 
different times. 

b) A given domain may have zero, one, or several processes 
executing in it at any given time. 

In such a scheme, two types of communication mechanisms are required. 
One is interprocess communicati on, which allows; two parallel pro- 
cesses, in the same or different domains, <to synchronize their 
execution and exchange messages. The other is interdomaln 
communication , which occurs at the point in time when a process 
crosses from one domain into another. This is generally viewed as 
being much like a procedure call/return sequence, including the 
passing of parameters, and is thus referred to as a domain-call . 
This will be discussed in more detail later. 

In actual systems, one or both of two simplifying restrict ions 
is often imposed. The first restriction is to force a given process 
to always execute in the same domain. This eliminates the rather 
complex machinery needed for domain-calls , and forces all 
Called "environment binding" by Jones [Jo 73] . 
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inter-domain communication to be cast as inter-process communication. 
While this is clearly a simplification of the hase-level system, 
in practice it often forces higher level software to essentially 
simulate domain-calls using multiple processes, only one of 'which 
is active at any give* time; This is not only inefficient, but can 
also be surprisingly clumsy, considering that parallel processes ^ 
seem to be such a powerful construct. Indeed, the unused potential 
parallelism seems to cause much of the ciumslnesi. 

The other restriction which la t>f ten applied is to allow only 
one process at a time to execute in a given domain. This can be 
done dynamically, treating the domain as a "critical section, " but 
is more often done statically, by associating each domain with a 
single process, and allowing only that process to execute in it. 
One reason for making this restriction is the previously mentioned 
correspondence between domains and address spaces. As pointed out 
by Lampson (La 69] this tends to result in address conflicts between 
multiple processes executing in the same domain. One way to avoid 
these conflicts is to equip each process with special base registers, 
or a pushdown stack for working storage, but what such mechanisms 
really provide is simply the ability for each of the processes 
executing in a given domain to see the domain somewhat differently, 
in a rather stylised way* A more straightforward and flexible 
approach is to actually provide a dMfere^t ^opy 1 * of the domain 
for each process, and to use the standard sharing mechanisms to 
avoid redundant Storage Of the identical components of these domains, 
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(e.g. pure procedures, unchanging capabilities, etc.}.* In such a 
scheme, each process has a private sat; of domains, end aowes among 
then using the domain-call Mechanism. Such -a aobema will be assumed 
in subsequent discussions of IC&, although this is not essential 
to the proper functioning of the improved canahiAitg aerhenlnne 
proposed later* ,■ -s- . 

Given that a domain possesses sos«, capability, it is allowed 
not only to use the capability to access the- indicated object, but 
also to manipulate the capability itselfe in eerteda cajttfully 
constrained ways, including,: 

a) Conylnf : the capability may b* freely, copied at any time, 
here denoted by a siiaple assignment 

*■» * °* 

b ) Seducing, privileges ; the privilege* in the capability 
nay be reduced, here denoted by 

reduce (C ,P) 

a 

where P is a mask indicating the subset of C ft »s 
previous privileges which are to be retained* 

In some systems [St 73] these two operations Have beea conbined; 

here,, they are presented separately to ease the latey transition 

to an improved scheme. 

One use of the mechanisns described so far would bs .the 

We will assume that a domain is created by an explicit create- 
domain operation, and remains in existence until destroyed [St 73], 
A aore complicated approach provides the automatic or eat ion of a 
domain whenever a call is directed to a global domsSn-ptototvpe 
object [Wu 74}. 
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passing of capabilities between domains via shared segments. In 
one sense, this is a very powerful feature, since it allows any 
possessor of a privilege to pass it on without requiring any sort 
of approval by the original donor of that privilege (except in the 
special case in which the donor is empowered to disallow all such 
sharing; e.g. in the case of a "confined" subsystem [La 73]). In 
another sense, however, this feature is very weak, since it pro- 
vides only a relatively costly, clumsy and unstructured method of 
inter-domain communication. This weakness would be particularly 
evident in the case of mistrust between domains (e.g. "mutually 
suspicious" subsystems). Both of these considerations suggest that 
the domain-call mechanism should provide for the passing of capa- 
bilities, as well as data, as parameters. The latter consideration 
suggests the utility of such a feature, while the former shows 
that the ability to keep a domain from giving away its privileges 
is already eliminated by freely copyable capabilities and is not 
further compromised by allowing the passing of capabilities as 
parameters . 

We assume that TCS allows the passing of capability parameters 
and implements this by copying the indicated capabilities from the 
calling domain (or caller) to the called domain (or callee) at the 
time of the call, and copying back any result capabilities at the 
time of the return. A domain-call thus takes the form 



call (C 6 »J? a »S 2 , - . . .?„) 



where the P. are parameters (data or capabilities) and C_ is 



20 



a gate capability for the callee, allowing activation at a particular 
entry point. Similarly, a domain-return takes the form 

return (R^,,.. ,l^ 

where the R are the results and the return gate is implicitly 
the site of the original call. We leave unspecified here such 
details as static vs. dynamic allocation of apace for capability 
parameters in the receiver's address space, automatic type checking 
of capability parameters, and so on. 

In addition to making unwanted accesses to objects, domains 
can misbehave by making unreasonable demands on the resources of the 
system [La 71]. Some mechanism Bust be provided to prevent them 
from interfering with each other in this manner. Since the details 
of accounting and resource allocation are beyond the scope of this 
thesis, we will simply assume that each domain is funded by an 
account, which limits its resource consumption. 

One particularly tricky problem which occurs in capability 
systems is the "lost object problem," which arises when all capa- 
bilities for a given object are inadvertantly discarded, making 
explicit destruction of the object impossible, and the space occu- 
pied thus unrecoverable. Given our attitude about accounting, this 
is really an opportunity for self-inflicted harm, rather than mali- 
cious sabotage. Nevertheless, recovery from such situations must 
be possible, hence several possible solutions to the lost object 
problem will be discussed at appropriate points. 
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2 . 2 Implemen tation of Capabilities in TCS 

In this section we discuss, in a fair amount of detail, cer- 
tain aspects of the implementation of a system like TCS. Three 
considerations influence the choice of the particular mechanisms 
described in this section. For one thing, various systems similar 
to TCS have been constructed, and their implementations, although 
varying in many ways, have shown some common features whose advan- 
tages have become generally accepted. In addition, certain facilities 
not included in any existing capability system are widely regarded 
as desirable, hence their implementation implications are of interest. 
Finally, discussion of implementation of TCS is. Intended to set 
the stage for the corresponding discussion in Chapter 3 concerning 
the implementation of a more sophisticated capability scheme. 

The most obvious necessity in implementing a capability system 
is some mechanism to protect the representations of the capabilities 
themselves from unauthorized alteration. The proper functioning 
of the entire system is based upon the integrity of capabilities, 
hence this mechanism should be simple, to maximize not only its 
reliability, but also its understandability, and thus inspire user 
confidence. Two mechanisms have been proposed, which we will call 
"partitioned memory" and "tagged memory." 

All capability systems which have actually been constructed 
have used partitioned memory. As its name suggests, this scheme 
involves partitioning the segments in the system into two classes: 
capability segments which contain only capabilities, and data seg- 
ments, which never contain capabilities. One obvious advantage 
of this mechanism is that the cost of distinguishing between 
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capabilities and data is distributed over an entire segment, reduc- 
ing the overhead per item, but the sain advantage of partitioned 
memory is more subtle; it involves the avoidance of certain address- 
ing complications which arise in the tagged memory approach, as we 
shall see shortly, the main disadvantage of partitioned memory is 
that the artificial division of a user's memory into two parts is 
inconvenient. It is often quite natural for information structures 
(e.g. entries in a table) to contain both data and capabilities. 
While such intermixing can be simulated using a pair of segments, 
this is a fairly clumsy procedure. For this and other reasons, 
discussed in detail by Fabry [Fa 74], we reject partitioned memory, 
as indicated by our specification of TCS as allowing free inter- 
mixture of capabilities and data in any segment. 

The tagged memory approach allows such intermixture by attach- 
ing one or more extra "tag" bits to each information item in each 
segment, the term "item" is used here to denote the basic address- 
lb le unit of memory (word, byte, etc.). these tag bits are unmodl- 
f iable by any software except the most central routine of the base- 
level system. Each Item's tag indicates its status as 'data' or 
'capability.' An item must be tagged as a capability to be used 
as one. An item so tagged can be generated only by copying another 
such item, or by the base-level capability-creation routine. On 
the other hand, a tagged capability can be erased by overwriting 
it, either with data or with another, capability, (the system could 
require that capabilities always be explicitly erased before their 
storage is reused. We reject this as too inconvenient for the user, 
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although there are cases in which it wou^d, ,majce t^ngs^ ^J^htXy 
easier for the system.). -.-. - .:s«: ■iUH.^p.t-. ;,*> ':■; 

The only production ^oaqjute^s ^ihi^h wsf |««S# ff*»°*y f* 6 
the Burroughs B5O00 [Bu^iJ u a»4.itS descendants,* .|he nrpjjected 
j,tems inches* machines ^re'-dfe^r^^^'V^lhei;^^ c^p^ilities. 
The dif£erencae«ba^en the tw do n^|,go^rtt J u| v hfre» ^ept for 
one; descriptor* are.considerebijr s soaker j-ghjn capabilities. A 
^ ¥ ^:ro^gh8 4«scrif tor is, 48 f bits lpng, w^^man^ex^end^ble capa- 
bility ■, systems, nave allowed in e*cega of 1QP bit:* fc f 6 |,each capa- 
bility. The impact of ;4 thi8^11,bfeofe if ae||y.in a foment ; 

While the advantages, of tagged femgr^hiv^bean, f 19*4^ « ain_ 
ing acceptance, another trend wh^c^^has^haf^fn^PriifpaCt: is 
the redaction of the size ^jtlie^addrfs^lf Ife^^n.pepry. 
While maclOnes wj*b items of 3<i, $m?M^^ 6 # b £&? jf e ^,; conBlon 
in the paj*, |^ r byjte ^,b^ch«rfc|e^) ^r**^^^ 9 * 1 ^ * 
universal standard, and. strong, ^^ar^^snt^ca^bigiiadf.for, the ulti- 
mafte reduction to bit, ad^reffa^^ppDX^s.^.^su^^iche^s, a 
larger unit of information <$,£* a,,cajab4£i^ a .if .represented by 
a contiguous sequence of i^en^.an^nape^iby fhe address of its 
first item piua its lei^ <i«pUe& W mfk^^/M^^'-. 
There, i? a very rea^ canf fict,, &&**& «**f*- 4MP £§#&$?* ' 
>: . Two ^oWeps aria* when the,, reni^aentAt^ o|,a £#$«?£. capability 
is a sequence of .add^easab^e &^fa,S4IW'io 9fl^^& ,imu 
increase in cos* of aea?o<;ia*ing *, 1^, wi*& eacb^ item as th*. items 
get smaller, The fltl|er j^. the gyaajbjj^tv ..^^h^^c^em^ of 

*Various exneri^itf^^ash^es tyBr%&P^£N^fflf$& l?* 1 ^ 108 
the Rice computers and Iliffe^s BUI. A general discussion of 

Jigged, tnempry^i*, &»*&W Pf^&kffi^- 
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addressing the aiddle of a capability. 

If we eesuae that each item has a «He ftft «ag. We are faced 
with iM qaestion of irhich of the ±te«s in a capability should have 
their tags on (I.e., set to 'capability'), if all 'of "'their tags 
are on, there is no convenient way for the systea to distinguish 
between a valid capability address, and one which points to the 
middle of a capability, the : latter case could laad to the recog- 
nition of th« list few itaas of one capability, together with the 
first few item* of an inSiediately following caoehility, as con- 
stituting a velid capability, hence ihis aa&ignlty aust he avoided. 
One way o* doing this is ta "data en 'only 'th* tag of the first itea 
in each capability, and require that the first (and only the first) 
ite*rioe*ted ly a capability address he so tagged, this ashes the 
other itea* in a Capability ittdistlnguishabl* frotfdeta, however, 
aha leaves -the* 'open to alteration ,; uaia§e;iv**y store operation 
scene the tftga of the appropriate marter of preceding iteas and 
turns thett ©if to insure Invnlldatinh of any capability which con- 
thins the itefr(s) being ftodif led. 

It i* cleat, then, that an address pointing into the ariddle 
of a capability nest he distinguished both frftn a valid capability 
address ahd froa «k address of untagged date. This suggests the 
need for two tag hits an each itea, <*n* Indicating whether the 
item is part of a capability at all, 'and the -^tSh^'mMlicating whe- 
ther it is the f iret Itea of a capability. Since the second tag 
is ftecesiwiry only when the first one is oh, it coiild he?' "ehelen'' 
from the hits of the itea only when needed (although this obviously 
doesn't work on a hit -addressable aeaory, 'Since r 'the. 'itea- would then 
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have no bits left at all ! ) . 

The other problem, the high cost of tagging small items, 
exerts a strong pressure to increase the size of tt^ems, Arguments 
in favor of small items generally cite the fact t;hat, for a given 
total bit capacity, address size grows only ; logari$bm^cel4y with 
decreasing item size. Unfortunately, the coj£ of tagging grows 
linearly, reaching a maximum in the bit-addressable .caae, of two 
tag bits per information bit, which is clearly put of the question. 

One alternative tagging scheme which we reject allows small 
items but imposes the restriction that capabilities can. only be 
stored at addresses which are an even multiple of the length of a 
capability. In such a scheme, memory, is item-addressable for normal 
data, while capability addresses must locate one of the predeter- 
mined "capability frames." Such restrictions tend to complicate 
the software and sacrifice many of the advantages of item- 
addressability. 

A much more sophisticated scheme* whicli also involves the 
notion of a capability frame, attempts to exploit the fact that 
the assignment of tag bits to each item is a relatively ineffi- 
cient encoding of the set of possible data/capability configura- 
tions in a given region of memory. Even if capabilities can begin 
at any address, the number of different arrangements in a given 
capability frame is not large. At most one capability can begin 
in a frame, and can be preceded by one or more data items and/or 
the trailing items of a capability which began in the preyious 
frame. By associating with each frame the integer displacement of 
the capability, if ahy, beginning in the frame, it is possible to 
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simulate two bit tagging of each item. This is a somewhat compli- 
cated approach, but may eventually prove to be the key to bit- 
addressable tagged memories, since it allows the cost of tagging, 
like that of addressing, to grow only logarithmically with decreas- 
ing item size. This scheme also has the rather intriguing property 
that reducing the size of capabilities does not always increase the 
efficiency of memory utilization. For a given pattern of usage, 
there is an optimum size for capabilities , such that deviation in 
either direction Increases the total overhead for capability 
storage.* No existing system uses such a scheme, although it has 
been tentatively investigated by Gray [G* 73]. 

We thus conclude that our implementation of TCS should use one 
of three tagged memory schemes : 

a) Items should be single bits, and the scheme just described 
should be used to simulate two tilt tagging. 

b) Items should be a substantial fraction of the size of a 
capability, allowing a two bit tag per item at a reasonable 
cost. 

c) Items should be large enough to hold an entire capability, 
allowing a simple one bit tag per item. 



Assume, for example, a bit addressable memory in which the average 
object is N bits long *nd ,J* f9**t§A £° M % capabilities . 
Then the overhead for capability storage is the fraction of memory 
taken up by tags , plus the fraction holding |he capebi lities them- 
selves. As a function of the size c of capabilities, this is 

P( C ) . log^ 4. kc 
K ' c + log c * N + kc * 

For instance, if N - lb 5 bits and k - io, the storage of 64 bit 
capabilities requires a|»put 15? o| memory ♦ while reduction to 32 
bits or expansion to l2$"tits increases "the overhead to about 17%, 
and 16 bit or 256 bit capabilities require about 22*. 
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To simplify subsequent discussions, we adopt alternative (c) , 
although it would probably not be feasible for TCS as described, 
since capabilities are so large. In Chapter 3, however, we will 
describe a scheme in which capabilities fit into more reasonable 
sized tagged items. 

The second major implementation aspect to be discussed is the 
mechanism for mapping the IDs found in capabilities into physical 
addresses of objects. The most obvious solution would be to simply 
use the physical address as the ID, but that would imply updating 
all the capabilities for an object whenever it was moved or deleted. 
This is Impractical due to the proliferation allowed by free copy- 
ability, especially in a system allowing intermixing of capabilities 
and data in segments. 

Most capability systems have solved this problem by localiz- 
ing changeable information about objects in a system data structure 
and forcing all access to the object via capabilities to go indi- 
rectly through this structure, which has been referred to by such 
terms as "Master Object Table" [St 73], "System Capability Table" 
[En 72], and "Global Symbol Table" [Wu 74]. Here, we will refer 
to it as simply "the map." 

There is a one-to-one correspondence between objects and 
entries in the map. An object and its map entry are created and 
destroyed together. Since the capabilities for an object are not 
updated when it is destroyed, it is not satisfactory to use the 
location of an object's entry in the map as its ID, since that 
would prevent re-use of map space freed by object destruction. In, 
fact, the ID of a destroyed object must clearly never be re-used, 



28 



since capabilities for the old object could then be used to access 
the new one. This suggests that IDs should be quite long, so that 
the space of IDs can never be exhausted, even if objects are created 
and destroyed at the maximum possible rate for the entire life of 
the system. The alternative of occasionally stopping the system 
and compacting the space of IDs is plausible, but less attractive. 
Any generator of a sequence of unique long integers can be the 
source of IDs. A counter of the total number of objects created, 
or a real-time clock of sufficient length and resolution are the 
common examples. In either case, provision must be made for 
restarting the system after a failure without any possibility of 
repeating a previously used ID. 

As a first approximation, we can consider the map translating 
such IDs into physical addresses as being implemented as a large 
hash table in primary memory, keyed on IDs. Figure 2.2-1 shows 
the representation of capabilities and map entries. (The field 
labeled "address" is assumed to contain any extra information 
necessary to distinguish between primary and secondary storage 
addresses. The details are not relevant here.) Each exercise of 
a capability involves: 

1) checking the appropriateness of the action, given the 
type and privileges in the capability (and signalling 
an error otherwise) , 

2) hashing into the map to verify the existence of the map 
entry, and hence the corresponding object (and signalling 
an error otherwise), 
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capability: 



type 
privileges 



object ID 



map entry: 



object ID 



address 



Figure 2.2-1: Format of capabilities 
and map entries in TCS 
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3) checking the address in the map entry for the presence 

of the object In primary memory (and signalling an excep- 
tion otherwise) , 

4) using the address to perform the access to the object. 
These steps are simple enough to be implemented in hardware or 
firmware, and would be used heavily enough to justify such imple- 
mentation. 

As described so far, the mechanism does not deal adequately 
with the two extreme cases of objects which are accessed very fre- 
quently, and those which are accessed very infrequently. Objects 
in the former class, such as segments containing executing programs, 
are so heavily used that hashing into the map in primary memory is 
unlikely to be efficient enough. Thus, it is necessary to hold 
the most active map entries in special hardware. 

In our implementation of TCS, this hardware takes the form of 
a special associative memory, each element of which can hold one 
map entry. The association is on IDs. On each access, the ID in 
the capability is first presented to the associative memory. If 
a matching entry is found, no reference to the map in primary memory 
is made. Otherwise, the standard map reference Is done, and the 
result replaces the least active (e.g. least recently used) entry 
in the associative memory, as well as being used to perform the 
access. The effectiveness of similar hardware has been clearly 
demonstrated in existing systems [Sc 71]. 

Whenever an entry in the primary-memory copy of the map is 
updated or deleted, any corresponding entry must be invalidated 
in the associative memory. This can be done by selectively 
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clearing the matching entry (if any) or by totally flushing the asso- 
ciative memory. The cost of reloading the entire associative memory 
on each such flush might be acceptable, but the extra complication 
required to do selective clearing is so low that it would undoubtedly 
be the method of choice. Mote that total flushing of the associative 
memory is never logically necessary, due to the ~ute~ $¥" context- 
independent names as association keys Similar mechanisms involv- 
ing association on context-dependent names require total flushing 
each time the context (domain, process, etc.) is switched. Of 
course, the significance of this is entirely dependent upon the 
frequency of such context switching. 

One apparent alternative to a special associative memory would 
be f the provision of a general purpose associative memory or "cache" 
holding the most active items in primary memory, regardless of how 
they are being used. Such a cache would naturally tend to capture 
the most active entries in the map, and thus speed up the standard 
machinery for accessing via the map in primary memory. In spite 
of its' appealing simplicity V'we' "reject this" scheme for several 
reasons. For one thing, a cache which is large enough to be useful 
for non-map items (e.g. instructions, data) is unlikely to be as 
fast as we can afford to make special hardware which captures only 
active map entries. Placing map entries in the same cache with 
other data also sacrifices any opportunity to access the two in 
parallel. In addition, the cache, by transparertly speeding up 
primary memory, in no way bypasses the hashing necessary to locate 
a map entry. This means that entire "collision chains" from the 
map, rather than just active entries, would need to migrate into 
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the cache , and would have to be scanned on each access , thus further 
degrading performance as compared with that of the special purpose 
associative memory. A more general way of stating all of these 
objections is to say that the cache simply melees the memory faster; 
th * relatlye overhead for accessing pimp entries in memory Is thus 
not reduced by the cache. Hence a cache, while valuable for other 
purposes , is not optimal for capturing active map entries . 

Another alternative which has been adopted in some systems 
stems from the observation that active capabilities,, as well as 
active map entries, should be held in fast hardware. To this end, 
programmable capability registers can be provided, into which ah 
executing program can load capabilities before use [Pa 69, En 72]. 
Moreover, the map entry corresponding to an active capability is 
itself active, suggesting that space be provided ._±mi the register 
for the map entry as well. An access via such a "smart" register 
can then proceed directly to the object. Of course, it is still 
necessary to automatically reload any registers holding copies of 
a map entry which is updated, which adds a certain amount of com- 
plication to the mechanism. Also, the addition of programmable 
capability registers, whether smart or not, introduces the standard 
problems of register allocation, save/restore sequences, and so 
on, as well as the novel requirement that a calling domain expli- 
citly erase registers containing capabilities not being passed as 
parameters. Other considerations in the use of capability regis- 
ters are discussed by Needham [Ne 72]. 

We adopt for our implementation of TC$ the associative memory 
approach rather than smart capability registers, although the 
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preference is not a strong one. We assume that the overhead of 
fetching the capabilities themselves from primary memory is suffi- 
ciently reduced by transparent mechanisms such as a program-counter 
holding the current procedure capability, or hardware implementation 
of all or part of the executing demaia's implicit segment. 

The success of the associative memory approach is completely 
dependent upon the observed taademey -for-smly a small number of 
objects to be heavily accessed duf i4g any given small interval of 
time (i.e., fraction of a second). I On a coarser time scale (i.e., 
minutes), the same kind of b e h avior* lytrfrsa rved in the sense that 
during a given coarse time interval most o| the objects in the 

■ " * 

system will not be accessed at all. | This suggests that the map 

1 
entries for such objects be kept in ^secondary memory, and be brought 

into the hash. tabla -to primary memory da^y when needed [Fa 74]. 

Experience with a similar scheme (the "Jkftive Segment Table'! [BCD 72]) 

in Multics shows that this approachlcan be quite successful tin 

: ,! '*t > 

j ...... »«.w» * 

saving a large amount Of primary memory' witlwut* incurring a signi- 
ficant spead penalty. 

Another aspect of TCJS.V. j^l»jmM|;*^«m-wtix»jMk.-4iscussed. ijp para- 
meter passing during domain calls, this is included mainly as 
background for a more elaborate scheme devepLoped.iix Chapter 4, 
hence it omits details not reIevant , *to'"t 1 Kit discussion. Figure 
2.2-2 shows, the workings, of the domain call instruction. First, 
the return gate must be retained, allowing re-entry into the caller 
at the site of the call. This is saved in a pushdown stack of such 
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gates which is associated with the process.* Then the parameters 
are copied from the caller's address space into that of the callee. 
We assume the existence of two sub-operations internal to the base- 
level system: 

P ■*• get_parameter (I,D) 
putj>arameter (I,D,P) 

These operations serve to fetch and store the I parameter P 
at the appropriate location in the address space of domain D. 
The actual layout of the parameters in the address space need not 
concern us here. We assume thatj H_, the number of parameters, 
and G_, the return gate, are automatically available to each base- 

K. 

level operation. (Most operations finish by exiting through G R ; 
the exceptions are domaln-cjii aid domain-return.) To simplify 
the discussion, we have omitted description of the copying of 
results from the callee bacfc to the caller when the return is done, 
since this is virtually identical to the handling- of the parameters 
during the call. Thus, Figure 2.2-3 shows only the retrieval of 
the return gate from the stack necessary to resume execution of 
the caller. 

In concluding our discussion of TCS* implementation, we 
briefly consider two possible ways to attack the lost object pro- 
blem, neither of which we regard as satisfactory. One approach 
is to maintain with each object a reference count of existing 

*A variant of the call operation, referred to as a "jump-call" is 
obtained by omitting the saving of the return gate. This causes 
the callee to return not to the current caller, but to the pre- 
vious caller. This is occasionally useful, as we shall see in 
Chapter 4. 
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Figure 2.2-3: TCS domain-return operation 
(without results) 
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capabilities, and to delete an object when it becomes lost, as well 
as when it is explicitly deleted.* There are at least three draw- 
backs to this approach : 

a) The destruction of capabilities (e.g. through overwriting 
or segment deletion) must be detected and the reference 
counts maintained. 

b) Lost self-referential structures are not deleted properly. 

c) An object may be lost to the user who funds it, even 
though capabilities exist elsewhere. 

We therefore reject the reference count approach, faor a contrary 
view, see Wul f, etal . [Wu 74]) . 

Another approach is to allow w un-losing'' of lost objects by 
allowing a suitably authorised domain (e.g. one which owns the 
funding account) to request spontaneous generation of fully privi- 
leged capabilities for funded objects |CC Wj. This is rather 
inelegant and requires fairly complicated data structures which 
may or may not be otherwise necessary. 

Other approaches to k base-level solution to the lost object 
problem can be envisioned (e.g. global garbage collection) but we 
choose instead to postpone the solution until a higher level of the 
system. Thus, the base-level system simply allows objects to 
become lost, and the users depend upon the directory system, as 
described in Chapter 4, to prevent this occurrence. 



* 
We assume that explicit deletion is alaos available, since other- 
wise, the user who funds the object may be unable to reclaim the 
space occupied by it. '?'*- 
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2.3 Revocation of Access Privileges 

In the context of TCS, we now explore various approaches to the 
distribution of capabilities and the revocation of access privileges. 
As an example, we use the simple situation in which domain A 
wishes to grant to domain B a set of privileges to access object 
X. 

The first approach which suggests itself is the simple copying 
from A to B of a capability for X containing the desired 
privileges, as shown in Figure 2.3-1. This is clearly the intended 
use of copyable capabilities, and Is quite satisfactory provided 
that the amount of trust A has in B remains constant ■ If , 
however, A subsequently decides that some different set of privi- 
leges is more appropriate for B, a second capability for X must 
be passed as a replacement. This may be quits inconvenient for B, 
who may have made various copies of the original capability, some 
of which may have been passed on to other domains. Moreover, 
unless the privileges in the new capability are a superset of those 
in the original, A must pessimistically assume that B will 
retain both capabilities, and thus possess the union of the privi- 
leges in the two. In other words* privileges once granted can never 
be revoked. 

This simple example shows that the typical capability mechanism, 
while useful, does not adequately cope with the difficult situation 
of changing levels of trust, particularly when trust decreases and 
revocation of privileges is desired. Before proposing any 
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We will generally omit the phrase "the person who owns a domain" 
and simply inpute feelings of "trust" and "suspicion" to the 
domains themselves. 
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Note: 



-► = object name 

-► = capability propagation 




i- X 



Figure 2.3-1: Passing a capability 
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fundamental changes to the behavior of capabilities, however, it 
seems appropriate to explore the various approaches which have 
been proposed for solving the revocation problem without making 
any major modifications to the underlying capability mechanism. 

Caretakers : A standard "escape hatch" in most protection 
systems is the ability to interpose a ,?4^atalil*!* domain between 
an object and the domains which access it. The caretaker can 
Implement any access control protocol not p»ov^ded by the system. 
This situation is shown in Figure 2.3-2, in which A has created 
a caretaker domain C, and given to ft a capability to call C, 
rather than a capability to access X directly. Two problems 
are immediately evident. ,J0ne is simply the inefficiency of 
calling C each time B accesses X. For example X may be a seg- 
ment, in which case the extra domain-call is likely to cost much 
more than the segment access itself. The other problem is that 
B now receives a capability of type 'domain' rather than one 
indicating the type of X. Unless the system provides facilities 
for allowing domains to "masquerade" as objects, this will change 
the Interface seen by B when accessing X# For example, to 
store into a segment, B must execute either a store-operation 
or a domain-call-operation, depending on whether or not a care- 
taker has been interposed. 

More generally, one can object that the caretaker mechanism 
is not, in itself, a solution to the problem, but merely a frame- 
work within which a solution can be implemented. We have said 
nothing so far about the basis upon which the caretaker C decides 
to allow or refuse a given access request. In the simplest case, 
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call-only 



Figure 2.3-2: A caretaker domain 
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A specifies a single set of privileges and gives a corresponding 
capability to C, who exercises it each time B (or any other 
domain having a copy of B's capability) attempts an access. When- 
ever A's level of trust in B decreases", a weaker capability can 
be given to C. On the other hand, ±t At-%±tAmm-t.o confer inde- 
pendently revocable privileges to acftees X on Various domains 
by authorizing them all to call C* £hen <§T, given that it can 
distinguish reliably between its various callers, finds itself in 
the position of a process in J*aJfcpsott'& "message system" {La 71]; 
that is, C must essentially re-invent the System's protection 
machinery. This can be avoided by diflninj multiple caretakers 
for X, each allowing an independent set of privileges, as shown 
in Figure 2.3-3. Since the icare^akefi In this situation are not 
really making any decisions * but a/e merely using their privileges 
whenever requested, one woulid hope that the overhead of an actual 
domain call might be avoided, Jwe will return to this point later. 

Control : Most modern protection systems provide some mechanism 
to capture the notion of one domain, being subordinate to, or under 
the control of, another domain. Thia is sometimes represented by 
a static domain hierarchy [St 133* but: «a vill treat control as 
being a privilege which, when contained in a capability for a 
domain, authorizes the possessor of the capability to control that 
domain. (The distinction is not very important fSt the discussion 
which follows.) In our typical system, much of the power of con- 
trol can be granted by giving one domain a suitably privileged 
capability for another domain's implicit segment, as was suggested 
in Figure 2.1-1, although complete control would require a 
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Figure 2.3-3: Multiple caretakers 
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capability of type 'domain' allowing access to the controlled 
domain's domain-descriptor. 

This facility for one domain to control another is applicable 
to a subset of our problem of Changing degrees of trust; domain A can 
attempt to enforce any reduction in its degree of trust of B by retain- 
ing control over B, although this requires that B have total 
and unconditional trust in A. The latter condition clearly limits 
the class of situations in which control of B, by A Is appro- 
priate. 

Even when the control facility is applicable , there are still 
problems with its use. It would appear eSafe. A, having given a 
capability for £ to controlled domain B, could later search 
the entire address space of B, reducing the privileges in all 
copies of the capability to match its revised intentions. The 
success of this search, however, can be compromised if B is 
allowed to execute concurrently, making the capabilities in ques- 
tion "moving targets." Thus, concurrent execution by B (or any 
other domain able to manipulate B's address space) must be pre- 
vented* either implicitly by placement in the same process with 
A, or explicitly by being "stopped" by A, using its control 
privilege. 

Even if A manages to successfully weaken the capabilities 
in B's address space, there remains the possibility that copies 
may have escaped to other domains which are not under A's control. 
To prevent this, A must carefully limit B's communication with 
other domains via shared segments, domain-call parameters, and so 
on. In short, B must be "confined," which, as noted by Lamp son 
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[La 73] can be both very restrictive for B and very difficult 
for A. In the latter regard, however, it is worth. noting that 
the problem of "covert channels" does not exist for capabilities, 
since transmission of the bits of a capability is not the same as 
transmission of the capability itself. 

A simpler mechanism which has been proposed [la 71, Gr 72] 
to deal with the above problems uses a "copy-flag" contained in 
each capability. Originally, the flag is on, to aJ.low copying, but 
once it is turned off, it can never be turned back on, and all 
copying of the capability is disallowed. Thus, A can place a 
non-copyable capability for X in B's address space, and later 
revoke any desired privileges from that capability, confident that 
no other copies exist. This is even more of a restriction on B 
than confinement, however, since free copyability is one of the 
fundamental properties of capabilities. If one assumes that the 
passing of capabilities as domain-call parameters is done by copy- 
ing, then non-copyable capabilities cannot even be passed as para- 
meters, making them virtually useless* The scheme can be salvaged 
by introducing "indirect capabilities" which point to the non- 
copyable capability and are themselves copy able, but, as we will 
see later, such an indirection feature is powerful _ enough to com- 
pletely eliminate the need for A to. control B in the first 
place. 

Ownership ; The idea of one user or domain "owning" a shared 
object has appeared in many systems, for such purposes as account- 
ing and resource allocation, as well as for protection. In the 
context of protection, the owner of an object is thought of as 



46 



retaining ultimate control over the object, in the sense that any 
other domain's capability for the object should be subject to revo- 
cation by the owner. Ownership , like control, could be defined 
as a static relationship between each object and its owning domain, 
but again, we assume instead that 'ownership 1 is simply a privilege 
which confers 'owner' status on any possessor of a capability con- 
taining it. 

As described thus far, ownership avoids the problems which 
limit the applicability of the control scheme. In particular, it 
is usable in the case of mutual suspicion, since it makes no assump- 
tions about the relationships between domains. However, several 
issues have been left unresolved. 

If the owner of an object wishes to revoke a given set of 
privileges from all outstanding capabilities for the object then 
the desired action is clear, if somewhat impractical. The base 
level system must suspend all other activity and search the address 
space of every domain in the system, performing the appropriate 
reduction on each capability for the object in question. It is 
worth noting that one case of such uniform revocation has a much 
more reasonable interpretation; if all privileges are to be 
revoked from all capabilities for the object, the owner can simply 
make a copy of the object and destroy the original . An even more 
efficient mechanism to produce the same effect can be provided in 
the context of the implementation in section 2. 2 by simply allow- 
ing the owner of an object to change its ED, thereby invalidating 
all outstanding capabilities [CC 69]. (Of course, the operation 
must return to the owner a new capability containing the new ID.) 
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If the owner of an object wishes to revoke individual privi- 
leges, a global search* Is implied, as indicated above. If, how- 
ever, the owner wishes to revoke ^hese privileges from some but 
not all of the capabilities if or tbie object, even more fundamental 
problems arise, the central question is how the owner should 

specify the set of capabilities on which the revocation is to take 

"'N 
effect. In the context qf TCS, the only obvious possibility is 

the. .ajAftif icati^n of a seft of domains iaJtt&th, the Revocation 

i ' , ,''... -«,:•« ; I 

should occur, either by listing the set, or by listing the comple- 
mentary set qf domains which should remain unaffected. The pro- 
blem is that in a system fprovid tog freely copyable capabilities, 
the owner of an object is; unlikely to have complete knowledge of 
the propagation of capabilities for that ols^mef" throughout the 

system, and is therefore ptot in a position to provide either type 

.< f ' 
of domain- list. ._ Figure 2.3-4 depifits~*he. «1 fCaltffn *|Ln whi£h A 

has given' capabilities fox owned object ~% to B and Ql Sub- 

:-■' ■■'■;' '% . -/ 

.**' •-,_*/- . %■ . ' ., " 

sequently, B and C have passed copies ot^^hfir ^capabilities 
to D and E, respectively. If A now decides to revoke some 
privileges from B's cjnj^illty, the revocation should clearly 
effect D's capability, but not \ C's or E's. A domain list pro- 
vided by A to control the revocation would specify either revo- 
cation from B, allowing D to escape, or exemption of C, 
incorrectly affecting E. 

There are other relatively simple situations in which no 
correct domain list can be prepared, regardless of A's global 
knowledge of the distribution of capabilities among domains. 
Figure 2.3-5 depicts such a situation, in which domain D has 
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Figure 2.3-4: Ownership 



49 



owner 
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Figure 2.3-5: Multiple sources of capabilities 
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received capabilities for X from both B and C. Ideally, revo- 
cation of B's privileges should affect the capability which D 
received from B, but not the one received from C. Such distinc- 
tions clearly cannot be expressed in a domain list, and require 
of A a completely unreasonable amount of knowledge of the inter- 
nal structure of other domains. 

Yet another fundamental problem involves the authorization 
of revocation by domains other than the original owner. In 
Figure 2.3-4, for example, B stands in much the Same relationship 
to p as A does to B, hence it would seem reasonable to allow 
B to revoke the privileges it granted to D. Since ownership is 
a normal privilege, A could authorize this by simply including 
'ownership' among B's privileges, but this clearly gives B too 
much power (e.g. the ability to interfere with C and E).. Simi- 
larly, in Figure 2.3-5, B should be authorized to revoke the 
privileges of the capability it has passed to D, but jiot the one 
D has received from C. 

Thus, the privilege of ownership, while sufficient to author- 
ize the total revocation of all capabilities for an object, is 
insufficient to deal with more general situations. 

Indirection : Most of the problems with revocation in capa- 
bility systems seem to be caused by the propagation of capabilities 
throughout the system. This suggests that domain A in our exam- 
ple should never give to B a capability for X whose privileges 
it may subsequently wish to revoke, but should retain the capability 
and give B a "pointer" to it. The success of this approach is 
very sensitive to the exact nature of the "pointer." 
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From domain A's point of view, the mojft obvious kind of 

pointer to the capability is simply its address in A's address 

space, but this address by itself is meaningless to B. To use 

the address , B needs to specify that it should be interpreted 

relative to A's address space, an action which clearly requires 

authorization in the form of a capability fox A (or for A's 

implicit segment) allowing capabilities in A's address space to 

be exercised, but not fetched or stored. , Giving such a capability 

to B clearly compromises A, however, since B may use it not 

only in conjunction with the pointer provided by A, but also 

with any other pointer B may invent . Moreover , this scheme 

also causes problems for B, since instead of a single capability 

for X, a capability for A and a pointer must be used. Thus, 

B effectively receives the absolute address <Q ,A> where A x 

A 
is the multi- level address of X in A's address space. These 

problems can be reduced somewhat by the obvious expedient of always 

passing the simple absolute address <C,d> of A's capability 

for X, thus limiting A's vulnerability to. a single segment, and 

guaranteeing that the pointer which B must handle will always 

be a simple displacement. Moreover, if this simple absolute address 

can itself somehow be squeezed into a single capability, both 

problems have been solved, since only the single "slot", in A's 

address space which contains the capability for X is usable by 

B, who need only keep track of the slot capability, rather than 

a capability and a pointer. Of course, care must still be taken 

to allow B to ignore the difference between a slot capability 

and a capability for the desired object. 
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Even ignoring the problem of squeezing so much information 
into a single capability, there are still restrictions on the use 
of indirection through capability slots. The problem is that such 
slots can never be reused. For example, suppose that A passes 
to B a capability for the slot containing one of A's own capa- 
bilities for X, as shown in Figure 2.3-6. If A later decides 
to revoke all of B*s privileges to access X by erasing the capa- 
bility from the slot, B still retains its slot capability. There- 
fore, A must be very careful never to place another capability 
in that slot. 

One Way of attacking the non-reusability problem is to squeeze 
still more information into the slot capability, namely the ID of 
X, and to check on each access that this ID matches the one in 
the slot. This eases the restriction somewhat: a slot may be 
used any number of times, but only once for any given object. Com- 
plete reusability of slots requires the inclusion of a "slot ID" 
in both the slot capability and the capability In the slot, to be 
compared on each access. This essentially amounts to re-invention 
of the unique ID mechanism of the base-level system, and is likely 
to be very cumbersome, for both user and Implementor. 

The non-reusability of slots in the indirection scheme is not 
really a fatal flaw. It simply forces the mechanism to be used 
in a rather stylised way. For example, domain A, rather than 
giving B a capability for some location In its own data struc- 
tures containing a capability for X, must copy the capability 
for X to some spot which will never be used for anything except 
indirection via B's slot capability. Actually, A would 
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Figure 2.3-6: Indirection through a "slot" 



54 



undoubtedly have made an extra copy for B's use in any case, so 
that subsequent revocation of B's privileges would not interfere 
with A's own accessing of X. thus, the only real burden on A 
is the careful allocation of slots so that they will never be 
reused. One approach would be te set aside one segment of A's 
address space and allocate slots in it sequentially. A much more 
attractive, if rather more expensive, scheme is the creation of a 
tiny new segment to hold each slot, Thib not only takes advantage 
of the base-level allocation machinery, but also implies that the 
displacement which we squeezed into the slot capability is always 
zero, and hence may be omitted. 

Privilege revocation by indirection through such "link" seg- 
ments is actually a fairly attractive scheme, which we pursue in 
some detail in the next section. It is conceptually related to 

'- I; 

% • 

both the caretaker and control scheme* discussed above. If one 
thinks of the link segments as domains, in the passive sense, then 
indirection through such a link domain is much like calling a 
simple caretaker which merely exercises its capability on demand. 
(Note, however, that the cost of an actual domain-call has been 
avoided.) On the other hand, from the point of view of its 
creator, this passive caretaker is a very well -behaved controlled 
domain, since there is no possibility of its capability being 
copied or moved. 



2.4 Indirection Through Link Segments 

Since indirection through link segments created especially 
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for that purpose seems to provide, many desirable features f or revo- 
cation, we now pursue th^s appr^oj^^qi^ewha^ oojre. v^oro^sly. The 
discussion is still in terms of TCS, in the senje that we attempt 
to minimize modifications to the^ ba^|-level system. And I construct 
the revocation machinery "on top of" that system. Although we 
will .later argue that a fairly c«g|le* f r^ocatiot* facility should 
instead be included in the base-le^l ;syste^. it is useful to 
explore this higher level implementation, as. a f ^irst step : 

As mentioned during the discussion of ownership, it is 
desirable for any possessor of a e^'ability to be able to distri- 
bute copies of it while retaining the power to revoke the privi- 
leges thus conferred. Thus, if access privileges pass through the 
hands of several distributors, the corresponding link segments 
form a chain. Capabilities accessing via that chain are subject 
to revocation by any of the distributors. Any possessor of such 
a capability may extend the chain by creating a link segment and 
storing the capability in it. Retaining a powerful capability for 
the link segment allows later reduction of the privileges in the 
capability stored there. If and when all privileges are to be 
revoked, the link segment can be destroyed. 

Thus far, we have made no changes at all to the TCS base- 
level capability mechanism, but neither have we provided any way 
for the indirection chains to be used to access the target object. 
This will require a fairly simple modification of the base-level 
system, but before describing that modification, it is instructive 
to observe precisely what goes wrong in attempting to do without it . 
In terms of our standard example of A giving B privileges 
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to access X, we find that A, in Figure 2.4-1, having created 
link segment ^ and stored its capability C for X there, 
must now give to B a capability C_ for S T '.' Clearly, B's 
capability C^ must not allow B to tamper with the capability 
in S L , but only to use it as a component of a multi-level 
address for X. (For example, if x is a segment, B's address 
for its 5th word, given that C. is located at location 3 of B's 
implicit segment S T , is 

3|0|5 5 <((C I ,3),0),5> = <(C L ,0),5> 5 <C x ,5> .) 

There are four interdependent problems with this attempt to 
implement link segments on an unmodified capability system: 

1) Son-transparency ; A domain accessing an object must 
know how many links are present in the chain leading 
from its capability to the object (i.e. how many O's 
to insert in its multi-level address, as in "3 fO 1 5" 
above) . 

2) Ambiguity ; A link in the chain is indistinguishable 
from a target object which happens to be a segment con- 
taining a capability in location 0. 

3) Subyertability : This is really Implied by problems (1) 
and (2) ; if the accessing domain accidentally or mali- 
ciously specifies a multi-level address which is too 
short, it can obtain a copy of a capability stored in 
the chain, thus circumventing subsequent revocation. 

*) Loss of selective adjustment in long chains : Only the 
last link in the chain contains a capability whose 
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Figures 2.4-1: Example of indirection 
through a "link" segment 
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privileges apply to the target object. Each earlier 
link contains a capability whose privileges apply to the 
next link in the chain. The only revocation allowed by 
such a link is total revocation by breaking the chain. 
All of these difficulties ar* avoided by a simple modifica- 
tion to the base-level system, which introduces a new operation 
on capabilities, and changes the behavior of the base-level system 
slightly when a capability is encountered to which this operation 
has been applied. 

The new operation aljowf a capability of type ' segment 'to 
be converted into a capability of type 'indirect' in which all pri- 
vileges are 'cm.' (As we shall see later, this is just a specific 
instance of a more general mechanism useful for type extension.) 
The intention is that such indirect capabilities for link segments 
should be handed out to domains which are being given revocable 
privileges. For example, in Figure 2.4-1, the capability C T 
which A gives to B must be of tvpe 'indirect,* although A's 
own capability for S is of type 'segment . ' 

Whenever an operation which expects a capability for some 
object encounters instead a capability of type 'indirect,* the 
indirect capability is followed ; that is, it is replaced by a copy 
of the capability in (location of) the segment to which it points, 
with any privileges deleted which did not also occur in the ori- 
ginal indirect capability. This step is iterated, as necessary, 
until the resultant capability is not of type 'indirect,' at which 
point the operation proceeds as usual. 

Thus, each time an object is accessed via a chain of link 
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segments, that chain is automatically followed to the target object 
unambiguously indicated by the first non-indirect capability 
encountered. The resultant capability is exercised, but is not 
otherwise available to the accessing domain , hence the chain cannot 
be circumvented. The privileges conferred are the intersection of 
those found during the entire scan of the chain, thus allowing 
independent revocation by each intermediary domain controlling 

a link in the chain. In other words, problems (1) through (A) 

-.■.... 1 i;.n.i;:„<!j-.i , ic -, ■.■Jmlx ■■•'■■".. r ' ^ 3siij /iy.il'Ji.i. »<•.':! xni rrnrs- 
above have been avoided. 

It is important to note that an indirect capability is 
followed only when it is used to access its target object; follow- 
ing is not performed when the capability itself is manipulated 
(e.g. by the copy or reduce operations). 

The indirection feature being described is fundamentally 
different, not only in design, but in intention, from the multi- 
level addressing feature of TCS. In some systems, such addressing 
has also been referred to as "capability indirect ion." A system 



in which both of these features were desired would require two 
separate mechanisms. 

Distribution of revocable capabilities using this scheme 
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involves five steps: 

1. Creation of a link segment. 

2. Conversion of a capability for that segment into an 
indirect capability. 

3. Copying of the distributor's own powerful capability 
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for the object into the link. 
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4. Reduction of the privileges of the capability in the 
link to an appropriate level. 

5. Distribution to the receiving domain (s) of copies of 
the indirect capability produced la Step 2. 

Any later reduction in level of trust can be enforced by re-execut- 
ing step 4, specifying some reduced set of privileges. 

Although this indirection scheme does a reasonable job of 
capturing the notion that a distributor of a capability should 
retain the power to revoke the privileges it confers, it gives 
one the feeling that the desired mechanism Is being "simulated," 
in the sense that the basic action of distributing a capability 
is provided by a particular non-atomic sequence of operations, 
rather than being an atomic operation. This has two consequences: 

a) It is inconvenient for the user. 

b) It may allow other sequences of operations to produce 
a non-meaningful state. 

The former problem can be easily dealt with by providing a simple 
library procedure to perform the actions required for capability 
distribution. The latter problem, however, is not so easily die- 
posed of. Suppose, for example, that by accident or design, a 
domain, in performing step 3 of the procedure /stores not the 
appropriate object capability, but the indirect capability created 
in step 2. This is just one way in which circular indirection 
chains can be created. Such chains, when followed, will cause an 
endless loop in the base-level system. Of course, one could deal 
with such a situation by placing an arbitrary limit on the length 
of an indirection chain to be followed before it is, abandoned and 
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an error is signalled, but this is rather ad hoc and inelegant. 
An atomic operation producing only well formed chains would be 
much more attractive. 

Another problem with this scheme is its relative inefficiency. 
For one thing, it would generate large numbers of small segments. 
This could be extremely costly in terms of both space and time, 
especially in a system using block-oriented rotating magnetic 
storage and a corresponding paged primary memory. For another 
thing, the scheme requires the following of a chain Of links each 
time an indirect capability is exercised. This overhead could 
prove prohibitive, particularly in the case of indirect access to 
segments. Moreover, any mechanism attempting to capture a compu- 
tation's set of recently used chains and retain them in fast hard- 
ware would be complicated by the fact that every store instruction 
would have to be regarded as potentially invalidating this "look- 
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back" information by overwriting a link in some chain. 

By comparison, if equivalent revocation features were built 
into the base-level system, they would probably be easier to use, 
harder to misuse, and more amenable to optimization. This approach 
is explored in detail in Chapter 3 . 



2.5 T ype Extension 

The definition of a large complex system as a sequence of 
"layers" has been found to be a valuable technique, aiding all 
stages of design, implementation, testing, and documentation 
[Di 68b, Pa 72, La 69]. In an object-oriented system, this implies 
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that not all of the various types of objects provided will be imple- 
mented, or even known about, by the base-level system. On the 
other hand, it would be most inconvenient if the naming and pro- 
tection machinery provided by the base-level system (i.e. capabil- 
ities) had to be reinvented by each new layer of the system; this 
would not only raise serious problems for the implementation, but 
would also force the users to interface with several parallel 
mechanisms for storing privileges, passing privileges to other 
domains, and so on. It is therefore very desirable for the base- 
level capability machinery to provide capabilities for objects 
of which the base-level system has no knowledge. 

The various base-level facilities involving capabilities can 
be divided into two categories. In the first category are the 
facilities involving capabilities themselves J their creation, 
integrity while stored, copying, erasure, and so on. In the second 
are the facilities for manipulating base-level objects named by 
capabilities: fetching from a segment or calling a domain, for 
example . It is the facilities in the first category which can and 
should be provided for higher-level objects unknown to the base- 
level system. 

As indicated in section 2.1, a capability provided by TCS con- 
tains the type of its corresponding object. The division of the 
set of all objects into types is a well known and intuitive idea 
(although, as pointed out by Morris [Mo 72], the difference between 
the type of an object and the privileges allowing access to it is 
somewhat indistinct) . , The set of objects provided by the base-level 
system falls into some small fixed number of types. The question 
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is: what type of capability is used to name a higher-level 
("extended") object? Various answers have been proposed, four of 
which we will explore. 

Approach 1: Representation ^apab^lifies. Any given layer of 
the system runs in an environment provided by the lower layers, 
hence any object it defines must be represented in terms of lower 
level objects. We will assume that the representation of each 
extended object is a single lower level object, since that single 
object can be a segment containing capabilities for any other ob- 
jects which are necessary. Thus the most obvious candidate for 
the capability for an extended object is. simply a capability for 
the representing object. A possessor of that capability could 
call the layer implementing that extended, type to request some 
operation, and pass the capability to indicate the extended object 
to which the operation should be applied. Having been passed this 
capability, the domain Implementing the extended operation would 
automatically have access to the representation of the object. 

There are at least three problems with this approach. The 
first and most important concerns the selection of an appropriate 
set of privileges to appear in the capability. The difficulty is 
that the domain implementing the extended object requires essen- 
tially complete power to manipulate the representation, while 
wishing to deny such power to the using domain(s) in order to 
prevent tampering with the representation. If the same capability 
is used by both, this is clearly not possible. Hence, the imple- 
menting domain, having upon request, created the representation 
of a new extended object, and thus obtained a fully privileged 
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capability for that representation, oust appropriately weaken that 
capability before returning it to tile calling user domain. However, 
in order to guarantee its own future access to the representation, 
the implementing domain must do one of two things. Sither it must 
save a Copy of the original fully privileged capability for later 
use, or it must make arrangements allowing It to convert the weaker 
capability back into the fully privileged one when it later receives 
it as a parameter to some operation on the extended object. 

the first method obliges the implementing domain to maintain 
a global table containing privileged capabilities for all existing 
extended objects which its layer has created, and to locate the 
corresponding entry whenever it receives a weak user capability. 
This method is reasonable, if somewhat clumsy. 

The second method requires some facility similar to Jones' 
"amplication" [Jo 73], allowing the implementing domain to add 
specified privileges to capabilities of the type of the represent- 
ing object. Clearly, the power to amplify capabilities of a given 
type is a very dangerous power, and must be tightly controlled, 
since it can completely subvert the Inter-user protection of 
objects of that type if misused. While this is an incomplete sub- 
version of the objects in question, In t^ sense that they still 
follow the semantic rules which define their type, it must be 
regarded as a failure of the corresponding layer, since the correct 
functioning of a layer includes the protection of its users from 
each other. Thus, the authorization of amplication must be the 
responsibility of the layer implementing the type whose capabilities 
are being amplified. One of the main criteria of layering, however, 
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is that a given layer should have no knowledge of higher layers. 
Thus, it is not possible for a layer tb distinguish between "legi- 
timate" higher layers which need amplification, and untrustworthy 
domains which would use amplification to gain undesired access to 
other domains' objects. We thus conclude that privilege amplifi- 
cation by itself is insufficient to solve the problem of assigning 
appropriate privileges to the using and implementing domains of 
an extended object, given that the same type of capability is used 
by both domains. (In conjunction with another complementary 
mechanism ("constituent rights" [Jo 73]), however, amplification 
can provide a very powerful type extension facility which is equi- 
valent to one which we will describe later.) 

The second problem with the representation-capability approach 
involves the control of access to the extended object , as opposed 
to its representation. Privileges are needed in each capability 
to specify which of the operations on the extended type are author- 
rized to possessors of that capability. This certainly cannot be 
done by assigning new meanings to the existing privileges, since 
granting the use of some operation on the, extended object would 
then imply granting some unrelated access to the representation. 
Hence, multiple sets of privileges oxe needed. Qn the one hand, 
this tends to make capabilities undesirably large. On the other 
hand, the number of sets of privileges provided places a fixed 
upper bound on the number of times a base level type can be extended. 
This situation is especially frustrating since in most capabilities, 
only one of the sets of privileges will be non-empty. 

The third problem with the representation-capability approach 
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is the difficulty of determining, given some capability, the type 
of the corresponding object. This is cawed by the "unofficial" 
status of extended types in this approach. A given base-level 
object may have been extended one or more times, but the type 
fields of all capabilities for it still contain its base-level 
type. The only indication that the capability is of a given 
extended type is the presence of a matching fully privileged capa- 
bility in the previously mentioned table kept by the domain imple- 
menting that extended type. Thus, one is not able to ask of a 
given capability "what is its type?" but only "is it of type T?" 
for some list of types T. This is a clumsy and costly substitute. 

Approach 2: Domain capabilities . This approach is, in some 
sense, a variant of the previous approach, in which the represen- 
tation of each extended object is a domain. A using domain has 
only one privilege in its capability for thia representation domain: 
the privilege of calling it. To perform an extended operation, 
the user performs such a call, indicating only the operation to be 
performed; the object to which the operation applies is implicit 
in the identity of the called domain. Actually, this approach 
falls outside the framework of our discussion, since it requires 
independent domains callable by any process (at least if extended 
objects are to be shared). It deserves mention, however, since 
it has been used in at least two systems [En 72, Fa 68], and 
because it attacks the three problems of the representation- 
capability approach, with somewhat mixed results. 

The first problem, that of easily allowing only the imple- 
plementittg domain full access to the object's representation, is 
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bypassed, since each object has, in effect, its own copy of that 
domain, which can retain a privileged capability for the rest of 
the representation in some convenient location in its address 
space. 

The second problem, that of controlling access to the extended 
object, is solved by embedding in the domain information about the 
operations it is willing to perform. Thus, privileges for extended 
objects are represented and controlled differently for base-level 
and extended objects; whenever a less privileged capability for 
an extended object is desired, a copy of the domain can be made, 
which is then ordered never to perform the operations being denied 
to receivers of the less privileged capabilities. This is not as 
expensive a solution as it might appear, for two reasons. First, 
the various copies of the domain representing a given extended 
object can retain in their implicit segments the information spe- 
cifying the operations they are willing to perform, and can thus 
share all the other identical components of their address spaces. 
Second, the capabilities for a given object exhibit a strong ten- 
dency to fall into a small number of subsets, each containing capa- 
bilities with identical privileges (a tendency which we shall 
exploit later). Thus, the number of copies of the domain repre- 
senting a given object tends to be much smaller than the number 
of capabilities for the object. 

The third problem, that of determining the type of a given 
object, is handled in an interesting if somewhat clumsy way. 
Clearly, examination of the capability will always indicate the 
type to be 'domain. ' One can establish a uniform convention, 
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however, for associating some arbitrarily chosen unique capability 
with each extended type, and storing a copy of that capability in 
some standardized location in each domain (e.g. location of its 
implicit segment) representing an object of that type. If users 
are allowed to examine that location, they can then reliably deter- 
mine the type of each extended object. The main objection to this 
scheme is that base-level types and extended types are represented 
differently, which disallows any uniform type-checking mechanism. 

There are some other problems peculiar to the domain-capability 
scheme. Two difficulties arise from the fact that the domains 
Implementing the extended type are associated with the objects of 
that type, rather than with the accessing processes. One reason 
for wanting to associate a domain with each process as the "repre- 
sentative" of a given layer is that the local storage of the domain 
provides a natural repository for information describing the status 
of that process from the point of view of that layer. This "own" 
storage is not provided by a scheme which associates domains with 
extended objects instead of processes [Fa 74]. Seme systems have 
made heavy use of such own storage (e.g. CAL-TSS, Multics) ; it is 
not clear to what extent this is intrinsically necessary. 

Another minor difficulty with the domain-capability approach 
is its Implicit assumption that all operations on extended objects 
are monadic. While this is undoubtedly the most common case, 
examples abound of useful operations which apply to two or more 
objects ("file- to- file copy"), to some large implicitly defined 
set of objects ("close all open files") or even to no object at 
all ("create a file"). Forcing such operations into the mold of a 
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call on a particular object is not only artificial for the user, "* 
but can be somewhat inconvenient for the lmplementqr. 

Approach 3; Sealed -data capabilities . This approach is moti- 
vated by the following observation about the use of representation 
capabilities in Approach 1: If the using .domains are not allowed 
direct access to the representation of an extended object, and if 
the implementing domain always replaces the user's weak capability 
with the corresponding strong one saved in its own table , then the 
user's weak capability is never actually used to access the repre- 
sentation. This suggests the possibility of changing the type 
field in the user's capability to contain, not the type of the 
representation, but some new value associated with the type of the 
extended object. There are two distinct advantages to this change. 
On the one hand, it provides an easily visible and unforgeable 
(given mechanisms to be described shortly) indication of the type 
of the extended object. On the other hand, it renders the capa- 
bility useless for directly accessing the representation, thus elim- 
inating the need for a separate set of privileges to control 
such access, as was required in the representationTcapability 
approach. 

From the implementing domain's viewpoint, the creation of a 
new extended object using this approach could be done by: 

1) creating a representation of the object 

2) saving a fully privileged capability for the representa- 
tion in a hash table keyed on IDs 

3) constructing a new capability containing the, extended 
type, full privileges, and .the ID. of the representation, 
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and returning it to the caller. 
When called to perform some operation, the Implementing domain can 
examine the passed capability: 

1) checking the type to verify that the object is one that 
it implements 

2) checking the privileges to verify that the requested opera- 
tion is authorised 

3) locating the representation capability in its table and 
performing the operation on the representation 

Clearly, the creation of capabilities for extended objects 
must be carefully 'controlled, since a forged capability could deceive 
not only the users, but also the implementing domain. The creation 
of capabilities of a given type can itself be authorized by a capa- 
bility. When this capability and an arbitrary datum are presented 
to an appropriate new base-level operation, a new capability is 
returned with the authorized type, all privileges *on,' and the 
datum as its unique ID. (As suggested above, this might be the ID 
of the representation, but could be any value desired by the imple- 
menting domain.) Section 2.6 will discuss how such authorizations 
to create new capabilities can themselves be created and distri- 
buted. 

The sealed-data approach as described is a quite acceptable 
type extension mechanism, and has in fact been used in at least 
one actual system [St 73] . It places each higher layer in much 
the same position as the base-level system; a capability is regarded 
as holding an ID sealed in a tamperproof box, which guarantees 
that the name presented by a user is in fact a valid name given 
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him by that layer. Furthermore, it allows this without forcing 
re-invention of the sealing mechanism in each new layer. It does , 
however, require that each new layer implement its own table for 
converting an ID into a capability for the representation of the 
corresponding object; this is a partial duplication of the function 
of the base-level "map" of section 2.2. It is desirable to avoid 
re- invention of the map, as well as of the capabilities themselves, 
an advantage possessed by our fourth approach to type extension. 

Approach 4; Sealed capabilities . The need for each layer to 
maintain a table mapping extended object capabilities into repre- 
sentation capabilities can be eliminated if the syftem simply 
allows each extended capability to c o n tain the corresponding repre- 
sentation capability. The extend^ capability £hus becomes a 
tamperproof box holding another capability! On the surface, this 
makes it appear inevitable for capabilities to. grow larger and 
larger as objects are extended retpeatedly^ a jprf*lem already dis- 
cussed in connection with our first approach to type extension. 
A carefully desigped implementation, however, ^.eajv, avoid this 
phenomenon, allowing unlimited extension with fixed size capabil- 
ities, as we shall see in section 2.7, which discusses the sealed- 
capability approach in more detail* First, .jgpa$tr, <we digress 
briefly to examine some more general questions about type extension. 



2 - 6 Hierarchies of Objects and Types 

In a non-extendible system* only -a small, fixed number of 
predefined types are provided, hence, types can be^ identified by 
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small Integers. In an extendible system, a much larger set of 
types is needed. Two conflicting considerations influence the 
choice of the size of this set. On the one hand, it is desirable 
to minimize Che size of type identifiers, Since these appear in 
capabilities, where compactness is a great virtue. On the other 
hand, It is desirable to maximize the total number of types 
available, to insure that the supply will never be exhausted, 
especially since type identifiers, like object IDs*, can never be 
reused. 

Emphasizing the first consideration results in a system in 
which the number of types, while much lafger than the number which 
would ever be legitimately used, is Still fairly modest (e.g. thou- 
sands or millions of types) fSt' 73] . This leaves open the possibility 
of a malicious program using up all available types within a few 
minutes of determined computing. Types in such a system must 
therefore be viewed as a finite resource, and must be allocated 
as such. This is possible, but somewhat inconvenient. 

Emphasizing the provision of an inexhaustible supply of types 
results in a system design in which the space of type identifiers, 
like the space of object IDs, is effefctlvely inlfinite (i.e. too 
large to be exhausted during the lifetlaie of the system) . By 
combining these two infinite name spaces, the ffflSRA system {Wu 74, 
Jo 73] provides an elegant conceptual framework in which types are 
themselves objects. This is illustrated in Figure 2.6-1, which 
depicts the set of all objects as fd«yiag--*-S6h'W^ievel tree. For 
purposes Of this figure, only two attributes of each object are 
of interest. One is its ID. The other is its type, which is 
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An object: 





Figure 2.6-1: Three-level object hierarchy 
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simply the ID of some other object.* Insisting that the other 
object so identified be of type 'type,' and providing a special 
root-object with ID 'type' (which is §leo of type 'type') forces 
all objects (except the root) to occupy either the second or third 
level of the tree. The second level contains the types, while 
the third level contains the non-type objects. 

Creation of objects in such a scheme can be described concep- 
tually as a single operation:' 

C .. ■*- create object (CL ) 
obj — J x type' 

where the new object will be a type if,,, C,^ ,1s a capability 

•■ type 

naming the root object, and a normal object if C. is a- capabil- 
ity. naming a second level object. If »C _, namea a third level 
object, an error is signalled. In practice, of course, such a 
unified base-level create_object operation cannot replace the 
specific object-creation operations for; the various extended types, 
since only the eorrespoaJing iayjfer has both the authority and the 
knowledge needed tto create and initialise the various components 
of the representation of a given type of extended object. 

The practical disadvantage of the viewpoint just described 
is the large size of type IDs. Nevertheless, we adopt the HYDRA 
view of types as being objects. In Chapter 3, we describe a scheme 
which manages to adopt this point of view, and yet provides an 
extremely compact representation for capabilities. 

There is a second kind of hierarchy among the types in an 
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Unique IDs, which are simply long integers, are shown as symbols 
in Figure 2.6-1 for clarity. 
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extendible system, which has been described by Morris [Mo 72]. 
This second hierarchy involves only the types, rather than all 
the objects, and attempts to characterize the layered nature of 
the system. Figure 2.6-2 illustrates a simple example, in which 
segments are assumed to be predefined, and various plausible 
extended types are shown, each indicating the type of its imple- 
mentation. This assumes that all\ objects of a given extended type 
have the same type of representation, which does not seem unreasonable. 
One can find examples, however, o;f situations in which differing 
characteristics of objects of the same extended type might make 
different types of representations desirable. In Figure 2.6-2, 
for example, one might wish to allow long documents composed of 
a collection of text files, which, according to our conventions, 
would be represented by a segment containing several text file 
capabilities. As another example, one might ^wish to represent a 
customer list as a sorted file or as a linked list, depending on 
the frequency of insertions and deletions expected. Jta the general 
case then, the types form not a simple tree, but a directed graph 
without cycles . The latter property expresses the partial order 
induced on types by the layered structure of the system. Note that 
for any given extended object, there is only one representing 
object, hence for a given representing object, the extended objects 
it represents can form at most a tree. (Of course, in any realistic 
situation, this tree is only a linear chain.) 
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Figure 2.6-2: A type tree 
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2.7 Type Extension Using Sealed Capabilities 

We now return to the last of our four approaches to the naming 
of extended objects, that using "sealed capabilities." As in the 
sealed-data approach, the manufacture of extended capabilities 
must be carefully controlled to prevent forgery. Given the view 
that types are objects, the appropriate authorization to manufac- 
ture a capability of a given type is a capability of that type. 
A layer can obtain a new type T by executing 

C T +• create_type ( ) . 

Subsequently, it can seal any capability C by executing 

C g - seal fr^Cj) 

as illustrated in Figure 2.7-1. C g will have type T, all privi- 
leges on, and a new unique I|> aaalgned by tie system. 
Later, C can be recovered by executing 

C* unseal (C a ,e T ) . 

Note that C T must be presented to authorise unsealing, thus pre- 
venting any random possessor of C from obtaining the capability 
C which is sealed inside. 

The implementation of capability sealing as just described 
requires a fair amount of machinery, such as that to be deacribed 
in Chapter 3. However, a slightly restricted version of capability 
sealing can be added to TCS in a surprisingly simple way. In the 
description below, we assume that a layer wishes to implement 



78 



C g *■ seal(C,C T ) 



type (T) 




privileges (all) 


X. 




ID (new) 
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n. 
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X 



type 



privileges 



ID 



Figure 2.7-1: Sealing a capability 
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extended objects of type T whose representations are of type T 
The creation of type T x is performed by the operation: 

(^ + ereate_type (T^V 



Note that the type of the representation (T ) must be specified . 
This is one of the restrictions necessary for -"the implementation 
described below, and forces the set of types to form a tree, as 
discussed in the previous section. Also, a set of privileges (P ) 
must be specified, whose significance will be explained below. 
The resulting capability for the new type (€L ) allows the crea- 
tion of new capabilities of type T , containing representation 
capabilities of type T sealed inside. 

The creation of an extended object involves the creation of 
its representation (which results in a capability C ), followed 
by the creation of a capability C for the extended object, using 
the operation: 



C x .*■ seal (C^,C^ k i-.ii-- 
x 

This produces^ sealed capability 0^. The second restriction in 
the scheme is the *mv&rmmi!idtim&-* Cy contain at least the privi- 
leges in P r . (In •ja?a J ojtftce ,.,-t*itai -i» ■ m^:pmb^mmi\- ^tmm ^e&ling is 
generally preceded by the, ojraa^iom oJ ;-jth#i raprnsentafcionv *hich 
produces a fully privileged cianaMMiRjtj ^)i. f ; 

Later, whenever the implementing domain receives as a para- 
meter a capability C^ of the new type, it can recover the sealed 
capability C f using the operation: 
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C «- unseal (6 ,C_ ) 
r x T 



Mote that the recovered capability C has exactly the privileges 
P , which cannot be greater than the privileges in the capability 
originally sealed. Thus, the layer which implements the repre- 
senting type need not trust the layer implementing the extension, 
since the latter can only recover privileges which it had previously. 

The scheme just described can be implemented by representing 
the extended type as shown in Figure 2.7-2. The Implementation 
of sealing now consists of merely changing the type field of C 
from T to T and turning on all privileges to produce C , 
while unsealing simply changes it back and sets the privileges to 
P , thus recreating C_ again. Note that C will thus contain 
the same object ID as did C , rather than a new ID provided . by 
the system. In practice this is not a serious problem. 

This implementation clearly allows a given object to be extended 
one or more times, and still be represented by a standard-sized 
capability. Variations on this scheme which depend on short type 
IDs are described by Sturgis [St 73] and Lindsay [Li 73] . Another 
related schema is the "eons*iFtye*MI;*»ig1i^ by 

Jones [Jo 73}, which is essentially e^Uive^tot to seeHng a segment 
containing several capabilities. Chapter s # %ua/nma**fi^v : * scheme 
which, eliminate* the restrictions described above, ^tot»wiK%: arbi- 
trary sealing of \ capabilities, i 



Figure 2.7-2: Representation of a type 
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2,8 G<mUub for a New Capability Systea 

Thla chapter haa attempted to set the stage for the proposed 
capability aecheaisa of Chapter 3 by sketching a typical capability 
systea, exploring the problem* of revocation and type extension in 
the context of that systea, and discussing various relstlvely ainor 
modifications to such a systea attempting to solve those probleas. 
In dismissing these modification, separately, examining both their 
strengths and their weaknesses, a number of dee ir able properties 
have been noted. Th*«e are listed below,, and are adopted as the 
goals to be ait by the design proposed in* Cheater 3. 



'SOU. 

1) Revocation should take effect immediately. 

2) it should be possible to revoke the various privileges 
in a capability Independently. 

3) It should be possible to selectively revoke the privi- 
leges of a subset of the capabilities for an object, and 
this should require no global knowledge of capability 
propagation. 

4) Any distributor of a capability (i.e. not Just the "owner" 
of the object) should be able to revoke its privileges. 

5) The users of capabilities should not need to distinguish 
between revocable and non-revocable capabilities. 

6) The cost of revocability should not be excessive. 

7) The aeehenisas of revocation and type extension should 
Interact correctly. 
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Chapter 3 
A New Capability System 

3.1 A New Capability System 

The goal of this chapter Is the description of a new capa- 
bility system (callefneSf^r sh$W which meets all of the goals 
listed at the end of Chapter 2. This requires a fairly substan- 
tial departure from the tCS system of Chapter 2. After discussing 
two abstractions of the '-link segment" scheme of Chapter 2, we 
adopt the family tree model to describe the revocation behavior 
of capabilities. The mechanism/ of generalized sealing is then 
proposed, to provide both revocation and type extension, and the 
practicality of implementing the scheme is argued in some detail. 



3.2 Design Considerations for Revocation 

In the design of the NCS capability scheme presented in this 
chapter, we wish to retain as imWjTa^pojfcible of the advantages 
of th* indirection scheme of Chapter 2, whi3*-avoiJ^ng f,ts pro- 
blems. There are at least two approaches {which can be taken in 
attempting to capture the essence of the indirection scheme in a 
base-level construct, as depicted in^f*f^cV"*f%la. On the one 
hand, as in Figure 3.2-lb, one can fregasd : ,.; : Q-. as being merely 

■j ■* A. 

a part of they mapping from C b to ifejgftjMBfc* *"* c as being 
a special revoker capability which allows that mapping to be broken. 
On the other hand, as in Figure 3.2-lc, one can regard both C 
and C b as being capabilities for the object, with C. being 
somehow dependent on C in the sense that revoking C 
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Figure 3.2-1 



85 



automatically revokes C, as well. 

Taking the former point of view results in a scheme in which 
the mapping from a capability to an object is Itself viewed as 
being essentially like an object, since one can have a capability 
for it and thus be authorized to manipulate it. To allow indivi- 
dual privileges to be revoked independently, one must define the 
mapping as containing, or at least limiting, the privileges of the 
capability. The establishing of one's future power to revoke a 
capability should be an atomic operation,- as discussed in Section 
2.4. For example, the situation in Figure 3.2-lb can be produced 
by executing 



C ' ■*■ revoker (C. ) 
r d 



Subsequently, the possessor of C can revoke the privileges in 
C, by executing 

revoke (C ,P) . 



In its effect on C,, this is equivalent to the TCS operation 



reduce (C, ,P) 
b 



The difference lies in the fact that, unlike reduction, revocation 
also takes effect in any and all copies of CL which may exist. 
The interaction of revocation with copying is clarified in 
Figure 3.2-2, which shows the situation resulting from executing 
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Figure 3.2-2: Interactions of copying 
and revoker capabilities 
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C *■ C 

y z 

C •*■ revoker (C ), 
r. y 



C «- C 
x y 



This kind of interaction causes subsequent revocation of C to 

affect C but not C , which is clearly the desired behavior. 

X z. . 

More complicated situations Include "subletting," as shown in 

Figure 3.2-3, in which both the original owner (holding C ) and 

an intermediate distributor (holding C ) retain the power of 

revocation over the user (holding C ), and "bill collecting," 

as shown in Figure 3.2-4, in which the ability to revoke the access 

of the user (holding C ) is delegated to a "collection agency" 

domain, with the owner (holding C ) retaining the option of later 

o 

disabling the collection agency if the contract with the user is 
renegotiated. Mote that the latter example takes advantage of the 
fact that revocsbllity, being authorized by a capability, is itself 
thus revocable. 

The revoker-capability approach .Jpst described has a good 
deal to recommend it, and has in fact been explored in some detail 
in a system design project at Stanford Research Institute [Neu 74]. 
However, we pursue here the dependent-capability approach instead. 
Investigation of the two approaches reveals the following advantages 
of this choice: 

a) It avoids the introduction of special capabilities 

authorizing revocation, thus simplifying matters some- 
what (although a certain amount of complication is 
unavoidable, as we shall see shortly) . 
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Figure 3.2-3: Subletting using revoker capabilities 
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Figure 3.2-4: Bill-collecting using revoker capabilities 
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b) It avoids treating the capability-to-object mapping as a 
manipulable object, which significantly reduces imple- 
mentation costs, but sacrifices the ability to make 
reyocability itself revocable. 

c) It can be cast in terms of a mechanism (to be described 
in Section 3.4) which unifies the notions of revocation 
and type extension. 

It must be admitted that the choice \& not entirely clear-cut; in 
particular, the opposite conclusion might be reached in a context 
in which revocable revocabillty was considered, important. 

One motivation for the notion of dependent capabilities is 
the observation that a weakened copy of a particular capability 
can arrive in the possession a domain as a result of either of the 
following sequences of actions: 

a) The privileges in the original capability are reduced 
to the desired set, and then a copy. is passed to the 
receiving domain. 

b) A copy is passed to the receiving domain, and then the 
extra privileges are revoked from the original. 

The essence of sequence (b) is that the granting domain "has 
second thoughts" and wishes it had used sequence (a) instead. This 
suggests defining the revoke operation by simply changing the 
reduce operation to be commutative with copying, in the sense that 



and 



revoke (C ,P) ; C, ' ■*■ C 
a d a 



C, *■ C ; revoke (C ,P) 
b a' a 
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produce the same net effect. Of course, revocation cannot be 
expected to undo any intervening exercise of the affected capa- 
bilities hence this commit at ivity applies only to the state of the 
protection structures, rather than to the 8t§£e of the objects 
being protected. Nevertheless, it is an attractive way of describ- 
ing the effect of revocation. 

Exactly how the revoke operation manages to find all outstand- 
ing copies of the capability being revoked is, of course, the cen- 
tral implementation question concerning this scheme. At this 
level of discussion, however, we simply imagine that a global 
search is done to locate and revoke the appropriate capabilities. 

Given' that we require commutativity of copying and revocation 
there are several possible schemes, corresponding to different 
assignments of dependency among the various capabilities existing 
for a given object. Clearly, the commutativity requirement con- 
strains the choice to assignments in which the dependency set of 
any given capability includes all other capabilities which have 
been derived from it through one or more levels of copying. He 
examine three schemes, corresponding to tfuree such assignments. 

Scheme 1 : The simplest scheme considers all capabilities 
for a given object to be interdependent , so that revoking privi- 
leges from any of the capabilities affects' them all. this approach 
is clearly unsatisfactory in general, for two reasons: 

a) All capabilities for a given object are forced to contain 
the same set of privileges. 

b) Any domain possessing a privilege can revoke it from 
all other domains. 
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Nevertheless, this approach has one virtue which makes it worth 
mentioning: it is possible to copy a capability and have the copy 
retain the revocation powers of the original. This is desirable, 
for example, when a domain simply wishes to move a capability 
within its address space. 

Scheme 2 : A more appealing scheme considers the capabilities 
for a given object as forming a "family tree" generated by the 
copy operation as follows: 

a) The initial capability (produced a£ object creation time) 

occupies the root node of (th^ tree.; 
• ■ . ■.- ,■ \ '•-■■- ■■ -•> . / 

b) Whenever an existing capability i* copied, the copy occu- , 
pies a new son node of the node containing the capability 
being copied. 

A typical family tree is shown in Figure 3.2-5. By defining a 
capability to be dependent on each of its ancestors in the family 
tree, we maintain at all times the condition that no capability 
can have any privilege not possessed by all of its ancestors. 
Thus, revocation affects entire subtrees of the family tree. 
This tree-structured dependency solves the two problems 
encountered with version 1 above, since it allows different 
capabilities to contain different sets of privileges, and strictly 
circumscribes the effect of revoking privileges from any given 
capability. Thus domain A may pass capabilities to domains B 
and C, such that 

a) B and C have different privileges from each other, 
and from A, 

b) A may revoke the privileges of B and C independently, 
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Figure 3.2-5: A typical family tree of capabilities 
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and c) B and C may not interfere with each other, nor with 

A, by revoking the privileges. 
Unfortunately, by treating copying in this way, Scheme 2 sacrifices 
the one advantage of Scheme 1: the ability to produce a copy with 
identical revocation powers. A capability cannot be moved by copy- 
ing it and discarding the original, since the copy, being a son 
of the original would lack the power of revocation over other 
such sons, and would therefore be an inadequate replacement for 
the original. 

The problem is caused by twos conflicting notions of what 
copying, is fo£, Juggfesting that t»r^»flfen\ operations are needed. 

■: j ,< \ • - -■>■■- ' / 

Scheme 3 : gy combining the ^t ions o# Scheme 1 and Scheme 2, 
we define a "reduced family tree** of capabiHties generated by a 
pair of copy operations s / 

c b ♦■'JC (as in Scheme 1) 
C b «- son (C ft ) (as in Scheme 2) 

The reduced family tree is generated as follows: 

a) The initial capability occupies the root node. 

b) The copy operation produces a new capability occupying 
the same node as the capability being copied. 

c) The son operation produces a new capability occupying 
a new son node of the node containing the capability 
being copied. 

A reduced version of the family tree in Figure 3.2-5 is shown in 
Figure 3.2-6. As in Scheme 2, revocation affects entire subtrees. 
Thus, while Scheme 1 proposed a set of capabilities, and 
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Figure 3.2-6: A reduced family tree 
corresponding to Figure 3.2-5 
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Scheme 2 proposed a tree of capabilities, Scheme 3 proposes a tree 
of seta of capabilities. This 1st intended to capture the observed 
tendency of the capabilities for a given object to fall naturally 
into subsets containing equivalent capabilities (as mentioned" in 
Chapter 2). In this scheme, the capabilities in each family tree 
node always contain the same privilege*, ---alnc*. any ehatige^td 'one 
of them affects them all. Qn the »«Hif'4tmti capabilities in' 
different nodes of the family tree can contain different privileges, 
and interact according to the rules of descendant revocation. This 
contrasts with a ays tern like TCSj in whien any tvo -capabilities 
may contain different privileges, and reducing the privileges in 
one never affects the other. 

One valid complaint about this scheme is that it forces an 
early decision as to which capabilities one may av e nt u slly wish to 
revoke. The recommended policy would be to use a revocable capa- 
bility whenever there was any doubt concerning the trustworthiness 
of a receiving domain. Indeed, this is the justification for our 
reatr ic tion that capabilities with the same iav^eatlon status may 
not differ in their privileges. It seems intuitively reasonable 
that any level of trust less than complete trust may be subject to 
change, especially since incompleta trust is of ten based on incom- 
plete knowledge. Thus, the same reservations whleh prompt one to 
pass a capability with restricted t»**vi*eg?Ba should prompt one to 
make that capability revocable. i ^ ; 

Wa wish to adopt the reduced family ttee as the model of 
revocation behavior in NCS. The implementation described In 
Section 3.6 produces exactly this 1 behavior, in addition to a 
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sealed-capability type-extension aaehsnieev. .; ;Ia?-.:fihe implementation, 
these two mechanisms not only interact strongly » but alee display 
a. striking similarity, despite thsir sppSfWE^iy dissisdLlar^ defini- 
tions, lie therefore present, in Section 3*jfcM a*.*»ref general 
. mechanism which subsumes them both. >. It should; be emphoaisod .that 
this generalized ■echenlea does oft pr<n^.de any addltiooal privi- 
lege revocation features, but functions rather aet>m* .interesting 
descriptive device unifying two- n semi egly different , constructs . 
We will continue to uas,, the;, f airily, treewdsi^ 
appropriate. 



3.3 Interactions, with Type-fatcnslon 

.. In the design of HCS^ we wish to a«niM^^e^s««ttd-casabillty 
approach -fjO type extension, as described ta^awpfeer -:4«^ Ihe minor 
restrictions in the TGS capability sealing mechanism of Section 2 . 7 
will be eliminated, .but this is not -a sa^or iaprovenent. . What 
is crucial , however, 1# the proper in teredt ion of type-extension 
with, revocation. 

One aspect of such proper interaction has already been nen- 
tioned; it nust be . possible to revels* aeeeas to extended objects, 
as well as to base-level objects . .? Moreover,, such: .'.r evocati on nust 
be handled through the normal base-level revohe ope rat i«o. without, 
for example, any need, to explicitly notify ..'.Che,, layer which imple- 
ments the object that access is b*ina>jntv4ta(MW v-^ bur- 
den is. placed on the user of the extended c|^bl^.*;;«^b»ttg> .-certain 
mild constraints are placed on the implementing layer, t» we shall 
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see in Section 3.5. 

Another interaction which .must be handled properly is t;he 
revocation of capabilities for objects which are representations 
of extended objects. Since such capabilities can be sealed inside 
the extended, object capabilities (to any depth), the revoke opera- 
tion, during its hypothetical global search, must be able to look 
inside the extended object capabilities and remove the appropriate 
privileges from any eligible representation capabilities it finds 
there. This requirement rules out such implementations as that 
described for TCS in Section 2.7, in which a sealed representation 
capability has no explicit existence, but can be reconstructed on 
the basis of certain assumptions, the key assumption being that 
its privileges remain constant, which can be false in a system 
providing revocation. The Important point here is not that a 
layer implementing an extended type would normally be in the posi- 
tion of having its representation capabilities revoked, but that 
it must not be possible for the freely available type-extension 
mechanism to be misused to "hide" capabilities from the revocation 
mechanism. 



3.4 Generalized Sealing 

In discussing capabilities, we have sometimes referred to 
them as being information "sealed in a box." This characteriza- 
tion has been used by Lamp son [La 69], Morris [Mo 73] and others, 
and suggests the obvious generalization of repeated feeling, i.e. 
boxes within boxes. We have already seen one situation in which 
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such a construct was useful: the sealed capability approach to 
type extension. In this section, we propose a much more general 
capability sealing mechanism for NCS which not only allows type 
extension without the restrictions imposed in Section 2.7, but 
also provides for revocation which follows the reduced family tree 
discipline of Section 3.2. 

The act of sealing information in a box can have two conse- 
quences : 

a) Reading of the information is prevented. 

b) Modification of the information is prevented. 
Morris [Mo 73] has referred to sealing as being transparent if 
only restriction (b) holds, and opaque if both restrictions (a) 
and (b) hold. We wish to generalize this distinction to allow 
partially opaque sealing of capabilities. This is accomplished 
by using boxes which are partly opaque and partly transparent, 
the opaque parts of a box have information on them; they cover 
and override the corresponding parts of the capability sealed 
inside. The transparent parts of a box allow the corresponding 
parts of the capability sealed inside to show through, and to thus 
remain in effect. It is not surprising that thid selective "fil- 
tering" action can be used to capture the notion of privilege 
revocation, as we shall see. 

The ability to seal things in boxes is carefully controlled, 
as is the ability to unseal boxes and thus gain access to their 
contents. Various kinds of boxes are available; the sealing and/or 
unsealing of a given kind of box is itself authorized by an appro- 
priately privileged capability for a type. In this scheme, a type 
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is simply a template for making boxes. As we will shall see, such 
templates, when used in a particular way, generate a HYDRA-style 
3-level object hierarchy, but this is not an explicit part of our 
definition of types. The association of boxes with types should 
not be taken as meaning that boxes are themselves objects, which 
they are not. A box is merely the "skin" of a capability, and has 
no independent existence of its own. 

The format of boxes is shown in Figure 3.4-1. A type is just 
a template for making boxes, and a capability is just a box con- 
taining something, hence this can also be used as the format of 
types and papabilitiev One can ^hink of the |tields as being 
written as "trit strings" where each digit takes its values from 
{0,1, transparent}. The fields are all familial: from previous dis- 
cussions, with the exception of the "capability-ID" field. This 
field identifies the capability, and serves to distinguish it 
(and all copies of it) from other similar capabilities, even if 
their type, privileges and a&Secpt<J&, fields are the same. This is 
important, for example, during the hypothetical search which per- 
forms revocation of privileges. 

In spite of the alarming size of these capabilities, we con- 
tinue to assume that each addressable location in memory is capable 
of containing one. At the same time, we will take the apparently 
paradoxical view that each of the four fields in a capability is 
the full size of a data item which could be stored in the same 
location as the entire capability. This kind of behavior should 
come as no surprise in a system which allows capabilities to be 
nested to any depth without increasing in size. 
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capability-ID 



type 



privileges 



object-ID 



Figure 3.4-1: Format of boxes, 
types, and capabilities 
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The seal and unseal operations are fairly simple. Executing 

C g «- seal <C,C T ) 



creates capability C g by sealing C 4 in a be»x specified by the 
template contained in type T, as authorized by the privilege of 
sealing in C^,'. The box produced is a verbatim copy of the tem- 
plate in type T, with the exception that the capability-ID and 
object-ID fields, if opaque, will have the same new unique ID 
written on them. Executing 



C t- unseal CCg.Cj). 



reverses the process by removing one or more b^xes from C_ until 
it suceeds in removing a box whose typ# f itll^ 8 °P*V»*' ^ 
value of i|s fcype field must matck-thaf of -:tha,J template in type T; 
otherwise, an error is signalled and nq value is returned. The 
capability C T must contain the privilege of unsealing. 

Given the above mechanism, various kinds of templates can be 
defined, of which we will use three. 

The simplest kind of template is shown in Figure 3.4-2. It 
is completely transparent* aM.^^t^eaJbjsxes|we will call 
"lockers," sine* their only function is to prevent their possessors 
f j|om modifying their contents in any way * la particular , lockers 
are used to- control revocation, as will be discussed in the next 
section. A type containing this template is provided by the system, 
and a capability for the type, allowing sealing but not unsealing, 
is publicly available. 
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Figure 3.4-2 r A "locker" 
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Figure 3.4-3: A "revoker" 
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Figure 3.4-4: An "extender" 
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A slightly more complicated template ip. shown in Figure 3.4-3. 
It is transparent except for an opaque capability-ID field, and 
generates boxes we will call "reyokers." (Recail . f rom the defini- 
tion of the seal operation that each new revoka*; will thus have 
its own new capability-ID.) As will be seen, in .the next section, 
sealing a capability in a revokerbox is equivalent to generating 
a new son-node in the reduced family tree. A type containing this 
template is also publicly available for sealing, but not unsealing. 

The third kind of template is shown in Figure 3.A-4. It is 
completely opaque, The value of the type field 4# just the ID 
of the type containing the template, JJoxes generated by such tem- 
plates we will call "extenders.'.' Extender boxes provide a sealed- 
capability type extension facility as^descr^bjd px Chapter 2. 
Several types containing such templates are predefined by the system, 
and an operation is provided for creating r more such types an demand. 
These types are nojt made publicly accessible. 

There may be other kinds of templates which would prove 
interesting or useful, but we will not pursue this here. Instead, 
we turn to the relationship between 1&e sealing mechanism and the 
other operations of the base-level system* 

As mentioned previously, the base-level operations taking capa- 
bilities as arguments can be divided into twjo groups. Most of 
them simply "look at" the capabilities an the .names of objects 
which are their actual arguments. A few, of $|em.ftra directly con- 
cerned with the capabilities themselves. The treatment of capa- 
bilities by the former operations is quite simple: they always 
rely on the external appearance of a capability, regardless of its 
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internal structure of nested boxes. For the latter operations, 
the situation is more complex. 

In addition to the seal and unseal operations described above, 
there are four kinds of base-level operations which manipulate 
capabilities themselves: 

a) creation of base-level objects 

b) copying of capabilities 

c) erasing (overwriting) of capabilities 

d) revocation of privileges 

Each of these is now described in some detail. 

Creation *f base-level objects is involved with the capability 
mechanism in two ways. On the one hand, each new object must be 
named by Ad initial capability which is to be returned as the 
value of the creation operation, "The'' fabrication of this capability 
can best be described as the sealing of en empty extender box, 
using a type owned by the base-le^eliysteii as a template. Thus, 
base-level object creation depends oh sealing. 

On the othet hand , sealing depends on the previous creation 
of types, which ate base-level objects. Types corresponding to 
the various base level objects (segments, domains, etc.) are 
created at aystem initialisation time. At least the "root" type 
(tt - 'type 1 ? must be created "out of thin ait ," and in fact, all 
base-level types are presumably created this way (although concep- 
tually, one can thltifc of the Mse-levei s^tei usljog its own 
create_type i>peration, which would In turn use the seal operation 
specifying the root type as a template). 

Copying of capabilities is conceptually simple In titis scheme. 
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The entire capability, including any number of nested boxes, is 
reproduced exactly, so that the new capability is indistinguishable 
from the original. Thus, executing 



C l * C 2 



results in two identical capabilities," 

The overwriting of a capability with data or with another 
capability is also simple. The overwritten capability is destroyed, 
with no particular side-effects except for the obvious possibility 
that some previously allowable actions are now forbidden. 

The most complicated operation in this scheme is revocation, 
which is performed by executing 

revoke (C,P) 

which revokes from C (and all copies of C) any privileges 
which are zero in mask P. The outermost box of C is required 
to be a revoker. Note that the revoke operation, like the TCS 
reduce operation, is portrayed as modifying an existing capability, 
rather than producing a new one (cf. seal, unseal). Generalizing 
the discussions of Sections 3.2 and 3.3, we will hypothesize that 
the underlying capability machinery performs a global search any- 
time an existing capability is modified and reflects the changes 
in all copies of the capability, even those which are sealed in 
nested boxes.* (These copies are easily recognized by their 

l _ I II I I ' ' II I : I l - l 7 '- ., ' ! II '„ II, I, V , ' l| ! |l \ "j j i tf -V < S ^ ' ' ' ^ -h "l ■ l'i li d » ■> ' .. ,.1 7-rf l iU. I -H 

In the design being described, this hypothetical search is exploit- 
ed only by revocation. Section 3.8 will survey some possible ela- 
borations on the design, two of which would also depend on this 
search. At risk of repetition, we again tfaHdt out that this global 
search is only a descriptive device, and is not actually implemented 
as such. 
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capability-ID fields.) The particular modification performed by 
the revoke operator is the writing of an opaque at each posi- 
tion in the privilege field of C which corresponds to a in 
the mask P. This is orily done, however, if the outermost box of 
C is a revoker; the revoke operation refuses to write on any 
other kind of box, and signals an error if this is attempted. 

Operations must also be provided for testing the tag of a 
memory location to see whether it contains a capability, and if it 
does, for displaying the various fields of the capability. These 
operations are straightforward and require no detailed discussion. 



3.5 Examples of Generalized Sealing 

This section outlines some intended uses of the NCS sealing 
mechanism just described/ and reviews the goals listed at the end 
of Chapter 2, to assure that they have all been met. The descrip- 
tion of directories and other specific facilities which can be 
implemented using NCS capability sealing is postponed until 
Chapter 4. 

There is more than one reasonable way to use the NCS sealing 
mechanism for revocation, depending upon the exact situation (i.e. 
the number of domains involved and their relationships to each 
other). In the example situations below, it is assumed that 
domain A possesses a capability and wishes to pass it to one or 
more domains B. In choosing a method of doing this, A controls 
the possibility of later revocation of the various capabilities 
passed. 
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To illustrate the various situations, the sealed capabilities 
are shown as arranged in corresponding reduced family trees. Recall 
that sealing a capability in a revoker box corresponds to generating 
a new son node in the tree. 

The simplest s^tu^tipn JLe.ohe in which A completely trusts' 
B, and simply passes a copy (£_) of its own capability (C.) , as 
shown in Figure ,3*5/^ $h% *o#£ ::&qpo4gtjp$; a jwaj plp of this is in 
"system calls," in which A regards domain calls on B as being 
operations of its "extended machine." As will be Seen in Section 3.6, 
the passing of such nee-sealed capability parameters represents 
a considerable saving. This Is Very significant, since experience 
suggests that a great ^mm^pxiit?'' of domain calls executed are In 
fact system calls [SS 72J! There are also logical reasons for 
passing non-sealed jca^aMjHtfi#>s on certain kinds of system calls, 
namely those which sr# p«S% of extended mechanisms for capability 
storage and/or transmission, such as directories or message 
channels. 

If A does not have complete trust in B, then before pass- 
ing C A to B, A shonld seal it in a revoker box. By keeping 
one copy (C ) of the sealed capability, and passing another (C_) 
to B, A retains the. power *«f later revoking B's privileges. 
This situation is il^s»a*«e*e4 4n Figure 3.5-2. 

If A wishes to pass ...rjvocablf capabilities to the several 
domains B.,,B 2 ,. ..,B ,&^Hpi"«^terna^Lve would be the creation of 

h _ ::- ^»~--> / 

C as above by sealini C. JU» ^revoker, followed by the passing 
of n copies of C_ (denoted C_ ) . to the domains B., as 
shown in Figure ;3.5t3« <Uota that :*&** J* A»*t ttherjajteiation 
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Figure 3.5-1: Passing a lion-r«^cable capability 




Figure 3.5-2: Padding a revocable capability 




Figure 3. 5*3: Passing simultaneously revocable capabilities 
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which would arise if A passed C„ to B.. , and B.. , completely 

B. X X 

trusting B„-«-B , in turn passed copies to them.) There are two 
limitations to this use of the mechanism. One is the non-selectivity 
of A's power of revocation; revoking privileges from any of the 
domains B. requires revoking from all of them. The other limita- 
tion is the lack of isolation between the domains B. ; any of 
them is capable of revoking the privileges of all of them, which 
may be inappropriate. 

Both of these limitations can be avoided by simply handling 
each of the domains B. separately as in Figure 3.5-4. This 
allows selective revocation from each of the B, , and isolates 
them from each other in case they are mutually suspicious. For 
example, the various B. may be the renters of a program owned 
by A, in which case both of these considerations are important. 

On the other hand, there are situations in which A does 

not need to revoke the privileges of the various B. selectively, 

but does wish to isolate them from each other. For example, a 

professor may wish to grant access to a grading program to all of 

the students in his class. He certainly wishes to prevent the 

students from revoking this privilege from each other, but may 

well have no desire to revoke their privileges independently, 

especially since this is somewhat costly and requires that A 

retain and use n different capabilities CL . In this situation, 

R i 
A can produce a single C by sealing C. in a revoker box, and 

can then distribute the capabilities CL produced by in turn 

B i 
sealing C in a locker box, as shown in Figure 3.5-5. This not 

only eases simultaneous revocation, but is significantly cheaper, 
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Figure 3 . 5-4 : Piling ,^Ln4#|wn#!^itly, 
revocable capabilities 
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Figure 3.5-5: Passing Isolated 
aiisultaneousiy revocable capacities 
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given the implementation to be described. 

From this discussion, it should be clear that goals 2, 3, 4 
and 5 of Section 2.8 are satisfied by the proposed design. Goal 6, 
that of reasonable cost, will be treated in the next section, 
which proposes an implementation for sealed capabilities and dis- 
cusses its efficiency. This Xii^^a^''^y'"'g^' v t'» > tinat of immediate 
revocation, and goal 7, that of proper inte#a£tfon between revo- 
cation and type extension. teM^"£!M«^t]i^ J ''&b goals generate 
one fairly subtle problem, which muit be^ii'&Ilsed before all the 
goals can be considered satisfied . 

It is clear that "revocation as defined takes effect immediately 
in the sense that the privileges of the appropriate capabilities 
are immediately modified. This is only significant, however, to 
the extent that the corresponding dperation* on the object in ques- 
tion are immediately prohibited, i^cVW' J t^"dijitafs on the 
checking of the privileges by the operations. s Sdne can imagine the 
following kind of scenario, in which revocation is effectively 
delayed. Suppose that domain A in process P. passes to domain 
B in process P_ a capability to access X, which is an extended 
object implemented by layer L. Suppose that layer L is repre- 
sented by domain L. in P. and by domain L g in P g . Assuming 
that we can say nothing about the relative execution speeds of P^ 
and P_ [Di 68] the sequence shown in Figure 3.5-6 is one possible 
outcome, and produces an effective delay in revocation which is 
visible to A. Strictly speaking, the problem here is caused by 
the occurrence of step Al between steps B2 and B3, which should be 
executed together as a "critical section." Synchronisation between 
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in P. 



in P 



B 



Al. A revokes B's privilege 
to modify X 



A2. A calls L. to examine X 
A 

A3. L. returns to A the 
A 

original state of X 



A4. A calls L. to examine X 
A 

A5. L. returns to A the 
A 

modified state of X 



Bl. B calls L_ to modify X 
B 

B2. L verifies that B is 

o 

authorized to modify X 



B3. L performs the previously 
B 

checked modification of X 
and returns to B 



Figure 3.5-6 
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the base-level system and higher layers is fraught with difficulties, 
however, hence the following alternative seems preferable: when a 
layer is about to access the representation of an object, it must 
first lock all parts of the representation to be touched and then 
check to see that the requested operation is authorized . In many 
cases, this interlocking would be necessary anyway; the major 
change due to revocation is the moving of privilege checking inside 
of the critical section. (In particular this means that pre-check- 
ing of privileges as an integral part of the domain cail machinery 
[St 73, Wu 74] is not very useful in a system in which privileges 
are revocable.) 

in the context of figure 3.5-6, such checking would delay 
step A3 until after step B3. the crucial point is that this 
renders the situation indistinguishable* from one in which step B3 
occurred before Al. Thus, although an access may occur slightly 
after permission to perform it has been revoked, there is no way 
for a properly written (i.e. timing independent) program to detect 
this occurrence. 



3.6 Implementation of Generalized Sealing in NCS 
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As in previous discussions, we begin by describing the repre- 
sentations of capabilities themselves. A tagged memory location 
holding a capability appears to the user to contain a rather large 

amount of information, but in actuality it contains a short form 

~ "" ~ ^ — ' — T" r_ - , — 1 ' • >:. 'i "i> ■ ' ■'- 

Except for real-time delays. 
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of the capability, consisting of a "locker bit"* and the ID of the 
capability as shown in Figure 3.6-1. The other fields are stored 
elsewhere, and the ID is sufficient to locate then, allowing recon- 
struction of the complete long f o r m of the capability. 

The most important advantage of tbJLs approach is that it 
allows the changeable Information (e.g. revocable privileges) in 
all copies of a capability to be centralized and thus updated 
without a global search. This is crucial to the practicality of 
the scheme, and will be discussed in more detail shortly. 

This approach also allows the ef f ectiye storage of an entire 
capability in a single practical-sized word of a tagged memory. 
For example, on the terribly pessimistic assumption that a new 
unique ID is generated every 10 microseconds, the use of 48 bit 
words would allow the system to ru^ continuously for about a cen- 
tury without exhausting its supply of names. Using a name-space 
compaction approach and a somewhat more realistic level qf pessl- 
mism would probably allow the use of 32 bit words without requiring 
an objectionable frequency of system shutdowns to perform the 
compactions (i.e. once every few weeks or months, at worst). 

An attractive way to store the boxes which constitute the 
actual substance of the capabilities would be in a global hash 
table containing small fixed sized entries and keyed on unique IDs . 
The map, as described in Section 2.2, is Just such a structure, 
which suggests implementing each box as a map entry. This approach 
yields an Integrated structure for the reconstruction and inter- 
pretation of nested capabilities from their short forms. The 
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This is not the same as the tag bit on the capability, and will 
be discussed below. 
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locker bit 



capability 
(short form) 



capability-ID 



capability-ID 



type 



privileges 



contents 



Figure 3.6-1: Format of (short-form) 
capabilities and map entries 
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increase in size and complexity of the map machinery, while non- 
negligible, is not excessive. 

The format of a map entry is shown in Figure 3.6-1. The 
capability-ID, type and privileges fields of the corresponding 
box are represented directly, while the object-ID field is replaced 
by a new "contents" field which serves to locate the contents of 
the box. Map entries for various particular kinds of boxes are 
shown in Figure 3.6-2. 

Base level capabilities, while conceptually the same as other 
extenders, are represented in a special form. The contents field 
contains the physical address of the object, hence these map 
entries correspond to the map entries in a system like TCS. The 
privilege field would always contain all l*s since revocation 
does not operate on extender boxes, hence its value can be implicit; 
the space in the map entry is used to record the size of the base- 
level object instead. 

Normal (i.e. user created) extender boxes are represented 
similarly, but their contents are capabilities, rather than physical 
addresses, and they make no use of their privilege fields. 

Revoker boxes represent their transparent type and privilege 
fields as all l's. In the case of the type field, this value is 
a constant which is specially recognized by the capability recon- 
struction machinery. In the case of the privilege field, it is 
used as a mask, hence any O's written in it are effectively opaque, 
as required for revocation. 

Note that no map entry format is described for locker boxes. 
Locker boxes are so simple that they may be implemented in a much 
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Figure 3 .6-2 : Map entries 
representing various kinds of boxes 
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cheaper way. As shown in Figure 3.6-1, a single locker-bit in the 
short form capability, rather than a complete map entry, serves to 
Indicate the presence of one or more locker boxes. (Since they 
are transparent and non-removable, multiple c©j|aecsttfeiv* locker 
boxes are indistinguishable from a single one.) 

Given the described representations of the various kinds of 
boxes, the seal and unseal operations may be implemented as shown 
in Figures 3.6-3 and 3.6-4, respectively. The seal operation 
creates a new map-entry representing die new box and stores in its 
contents field the .capability being seeled. Seaiiis| in a locker 
box is handled specially by simply turning on the locker bit in 
the sealed capability. The unseal Operation simply returns the 
contents of the appropriate extender box. (Recall that revokers 
and lockers can never be unsealed.) Figure 3.6-5 summarizes the 
various low-level facilities used in the description of these and 
other operations . These are assumed to be clear from previous 
discussions, with the exception of capability reconstruction 
("Recap**)--!!!* iSgdciltive memory I^oliujp ("Capfind" and "Cont_find") 
which will be described shortly. 

The creation T0fe*chn«w base-level object includes the 
construction of the "root" map entry representing its initial 
capability. This map-entry is self sufficient, in the sense that 
it does not depend on any other map entry for its proper interpre- 
tation. On the other hand, a map entry representing a revoker or 
extender box contains another capability; its one-word contents, 
field holds the short form of the capability, hence its interpre- 
tation is dependent upon the other map entry holding the rest of 



^s;^!^*,*^W'»>**^ 



119 



Cg *■ seal(C,C T ) 



c *»**» ) 



|eca] 



W . \ n. 



C +■ !|ecap(c) 

c T * teesp^p 



T type»/ fV. 

Year 



.Lockefc ) - X ^^r*^% 







ERROfc 



3 






< — ) 



I + Nev_ID( ) 

M ■*■ Hw wapentry(I) 



f nh!Ut 7k \ 



Type(M) Xil..,l, 
Frlv(l0^jH...li 



HfWlHAM 




No 



. luij i Ji'iuK ' &ii* 



townnr 



Cont(M) ■*■ c 



Type(M) * Obj(C T ) 



Cap(c g ) /«- I 

Locker (c ) «- 
s 



tecit 



3 



Figure 3.6-3: NCS seal operation 
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Figure 3.6-4: NC$ unseal operation 
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Fields In various data structures (see also corresponding figures) 
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Figure 3.6-5 Low level facilities used by operations 
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that capability. Thus, repeated sealing of a base-level object 
results in the generation of a tree of aap entries, which combines 
the functions of the type tree of Section 2.6 and the reduced 
family tree of Section 3.2. An jt— pie of such a tree is shown in 
Figure 3.6-6, in which a segment is used as the representation of 
an extended object of type 'directory* * for which various capabilities 
have been distributed. 

It is important to note that while the seal operation 
generates such tree structures, the onsesl Ofpcmtion does not dis- 
mantle then. For example, in Figure 3.6-6, if the layer imple- 
menting directories unseala C« to obtain C_, the asp structure 
remains unchanged. The mechanism for deletion of ' unseeded map 
entries will be discussed later. 

In order to reconstruct the long form of a capability, it is 
necessary to examine the boxes which ciompiiBB it , srsrt tng with ^ the 
outermost ams^mmj^g^Jsjmsjem. until all fields are completely opaque. 
Given the particular kinds of boxes used in our scheme, this simply 
entails scanning down a chain of (sero or more) reyohers until a 
non-revoke* box is encountered. This reconstruction procedure, 
shown in F^sujce 3»j6r7^- 1# rather similar to the "following" proce- 
dure for indirection chains of Section 2.4. In other figures, the 
capability reconstruction procedure is referred to in the form 

C ■*• Becap (c) 

where c denotes the short form and C the reconstructed long 
form of the capability. In addition to the visible long form, the 
reconstruction process also recovers the represeiM^ation pointer 
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Figure 3.6-6: A map entry tree 



'- •*•» j|t»*»>V"~ ■■ h -f. -„ ., .. * i 



124 



C ■«- Recap (c) 




P * ll| n i.l 2 

• ■.rai.iii 



I + C«p(Cont(M); 
P>- PAPriv(MX 



•SWhi 




Cap (A) 
Type(A) 
PrivCA) 
WU> 
Sia»U) 
Coat (A) 



Cap(c) 

Typa(M) 

P 

Cap<H) 

PrivGO 

Coat (M> 



I 



I fv ii r . ' i i i n* ' 

I Saturn A b— • 

Ci j l» n nf ^ 



Figure 3.6-7: Capability reconstruction 
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from the capability to the object, which consists of the short form 
representation capability in the case of extended objects, and 
the address and size for base-level objects. Thus, the result of 
the reconstruction process is a mapping , as shown in Figure 3.6-8. 

The cost of the reconstruction process is relatively high, 
since it involves scanning a chain of map entries, each of which 1 ) 
must- be locate* by hash-tag into the map . The retention of the most 
active mappings in fast hardware thus becomes even more important 
than in a system Tike TCS. The as^sotfrar^rve^ memory discussed in 
Section 2.2 could be used without change to hold map entries from 
active chains and thus speedup the scan. On the other hand, a 
561 increase Tn fhe " size of thjfe associative memory entries allows 
them to contain entire mappings, .rather than single map entries. 
On the average, this modification would probably not provide a very 
dramatic improvement to apaajfe i(by vJvpNMfetr ^lejiwconstruction 
process entirely, rather than merely accelerating it) and might 
even slightly reduce the efficiency y <t£i0fm0m utilization in the 
associative memory (if the average chain length was less than 1.5 
map entries). It is desirable, however, since it allows a fixed 
amount of associative memory space to effectively contain a chain 
of arbitrary length, thus preventing long chains from severely 
degrading performance by filling up the associative memory. We 
therefore specify the associative memory as containing the several 
most recently used complete mappings. The exact number to be 
retained would depend on several considerations, ranging from 
available hardware components to expected usage patterns. Two 
factors which favor maximizing the number are the relatively high 



126 



Capability 



Representat ion 
painter 



capability-ID 



type 



J ' J.ii">" ; 'J 1 '""!"" 



privileges 



o1»i«ct-tD 



size* 

« ' W ill K il l I I.—*—— —»>»—»»< 



,U » . .J 1 

■QBMMaMfl 



coateats** 



* Base-level objects only 

** Address if base-level object 
* Representation 'CSp*»i*I*r (short ' for*) -<•»* extended ■ ob j ect 



Figure 3.6-8: A sapping 
<as stored In **fe : es*oc£e££*e< aaaory ) 



127 



cost of initial loading (- capability reconstruction) and the fact 
that the retained mappings remain valid through domain-calls and 

s ■■ - ■ . - - ■■■ .- - ■ * ■■■-.,';'*■<"--• ,£■■'*" 

process switching. 

In the various figures , the associative memory facilities are 
represented in the form: 

A * Capjfiae <X) 
A> Contftnd <X) 

Each of these finds an associative memory entry whose appropriate 
field (capability-ID or contents) contains the value X. If no 
such entry is present, the least recently used entry is found. 

The revoke operation is quite straightforward in terms of 
its effect on the map. Since all copies of a given revoker box 
are represented by a single map entry, the masking of the privilege 
field of that map entry automatically revokes the corresponding 
privileges from all the copies, including those sealed inside 
other capabilities. The only problem is that some of these latter 
capabilities may already have been reconstructed and saved in the 
associative memory, necessitating their removal. 

Unfortunately, the names of all such capabilities cannot be 
determined from the name of the capability being revoked, except 
by introducing a complicated and fragile backpointer structure 
into the map-entry trees. One way of dealing with this problem is 
to completely flush the associative memory on each revocation. 
This will be satisfactory if the frequency of revocation is rela- 
tively low. If revocation is a sufficiently frequent occurrence, 
however, this will drastically reduce fehe^utilMCydf the associative 
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memory by forcing heavy use of the expensive reloading procedure. 
A quite satisfactory compromise between total flushing of the > 
associative memory and selective removal of only the affected - 
capabilities is the removal of all capabilities for the same 1 
object. This is easily accomplished using the "Cont_find M feature 
of the associative memory, as shown in Figure 3.6-9. (For sim- 
plicity, we have assumed that is not a valid value of the 'Cap 
or Cont fie Id 8 of a mapping, and can therefore be used to disable 
an associative memory entry.) This semi-selective removal will 
sometimes force unnecessary reloading of capabilities which were 
not affected by the revocation, but this will only happen when a 
capability is revoked and another capability for the same object 
which is not its descendant In the family tree appears in the 
associative memory. 

The storage of inactive map entries in secondary memory is 
much the same in NCS as in TCS. Each TCS map entry corresponds to 
a complete tree in HCS, but only the active paths in the complete 
tree need be kept in primary memory. It seems likely that known 
techniques for localizing list structures in secondary memory t . 
[Bo 67] could contribute significantly to minimising the overhead 
incurred when an inactive path becomes active and must be brought 
into primary memory. 
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One possible frequent example of this would be reffcatsion of a 
domain-call, parameter upon returni from tbm, eaU* «ee©*aticm of 
the caHse's capability would unnecesaarily remove the caller' 4 own 
capability from th« associative memory. Tkda souli be. avoided us- 
ing a modification suggested by Peter Bishop of f^l.T.* in which 
the mapping produced by ,. the, .. capability reeomstrueaioa mechanism 
would include the length of the chain scanned to produce it. By 
comparing this value for the capability being rlwp^vam*.''the 
capability being removed from the associative mesjBry, one could 
avoid removing tree-ancestors of the revoked capability. 
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Figure 3.6-9: NCS revoke operation 
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3.7 Some Implementation Details 

In describing an implemented system, it is often desirable 
to omit or simplify certain details which, while necessary in the 
implementation, are of little intrinsic interest, and tend to * 
obscure the significant principles of the design. Unfortunately, 
in arguing the practicality of an unimplemented system like SCS , 
one is obliged to address such issue*. This section is involved 
with such details relating to the maintenance jbf the system data 
structure we have called the map. Benders whor find themselves' 
growing bored with the arguments can skip the remainder of this 
section without significant loss of continuity. 

The basic problem with the map as described thus far is the 
lack of any mechanism to keep it from filling up. For example, 
by repeatedly sealing a single capability at the relatively modest 
average rate of once per millisecond, a malicious domain could 
fill up a 1 million word map in a few minutes, in a system like 
TCS in which each map entry corresponds to a different object, jone 
might be able to depend on the limitation of other resource usage 
for the object to limit usage of the mep^apace. resource and pre- 
vent its exhaustion, this is clexrlyi mot the case in the new 
scheme, in which creation of map entries dees net imply any other 
resource usage at all. ; 

For this reason, it is necessary to treat map entries as an 
allocatable resource and thus limit the amount of map Space 
available to each domain via its account. An account's reserve 
of available map space must be decremented each time a domain it 
funds creates a map entry, and Incremented when the map entry is 
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deleted. This requires that each map entry contain an extra field 
specifying the account which funds it since this may not be evident 
at the time at which it is deleted. Since unused map space resides 
on secondary storage, it is quite inexpensive, hence the allocation 
given to each account can be sufficiently generous that no reasonable 
program would ever exhaust it. The limit serves only to contain 

a I ;'.(v : '.'. '■:'■<■"<< 'Mh ;.:■■■ ■■;..',• > . ?": > .iiOi '*.! <WU .> . i>9 *■;* ■•;;.'• -, ; .. • 

the damage done by pathological programs. 

From the system's point of view, the problem is now solved 
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since each user can harm only himself by extravagant use of map 
space. This is not really sufficient however; the consequences of 
such self-inflicted harm must not be too severe. A given . account ' s 
allocation of map space can be cluttered by an undebugged program, 
hence some mechanism must be provided for prevention of and/or 
recovery from such a situation. Prevention cannot reasonably be 
expected of the base-level system, since it cannot distinguish 
between legitimate and illegitimate use of map space, hence recovery 
must be possible. We take the point of view, however, that this 
recovery need not be particularly easy or graceful, since, as 
mentioned previously , most use of the sealing mechanism is expected 
to be made via more civilized facilities rather than directly. The 
implementation of such facilities will be discussed in some detail 
in Chapter 4. At this point we are only concerned that such faci- 
lities use sealing In an orderly way. 

What constitutes orderly use of the sealing mechanism? So 
far, no method has been described for removing unneeded map entries, 
hence any use of sealing will eventually fill up the map. The 
basic question is: when is a map entry no longer needed? There 
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are at least two circumstances in which this is true: 

a) Its privilege field is empty, < 

b) Its contents field points to a non-existent nap entry 
or object. * 

If either of these conditions holds, the asp entry is useless and 
nay be deleted. Condition (a) suggests the revoke operation, upon 
reducing the privileges in a nap entry, should check «£iether any 
privileges remain, and if not, delete the entry from the nap. > Con- 
dition (b) suggests that the capability reconstruction mechanism, 
upon encountering a map entry whose contents field contains such 
a "dead-end" capability (which we will sail an "isolated" entry) 
should delete it from the map. A map entry whose contents field 
contains the address of a base level object is deleted when the 
object is deleted, thus isolating any map entries pointing to it. 
In general, the deletion of a map entry can cause one ©if more 
other map entries to become isolated* and thus be deleted the next 
time they are exercised by the reconstruction process. In this 
way, entire isolated subtrees can be gradually eliminated. (The 
case in which such entries are never subsequently exercised will 
be discussed shortly.) 

Thus, in addition to its normal cleaalttg-uP activities 
(destroy ins; ummeeded objects, etc.), a well-behaved domain should 
revoke any uaneeded capabilities to clean up the map. ' 

Similarly, the problem of cleaning up ef ter the execution, of 
an undebugged domain involves deletion of uaneeded objects and, map 
entries, followed by deletion of the domain itself* Problems can 
arise if the faulty domain has discarded all capabilities for any 
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such object or map entry, which is then lost. A feature solving 
the lost object problem will be described in Chapter 4, but it 
would be expensive and cumbersome if used for every map entry. We 
therefore allow map entries to become lost and require that recov- 
ery from this situation be possible. This requires the revocation 
of all capabilities originally passed to the faulty domain, thus 
isolating the subtrees of map entries produced by its execution. 
The lost map entries in these trees will never be exercised, how- 
ever, since by definition there are no capabilities for them. 

For the reason just cited, some mechanism must be provided to 
exercise lost map entries. Moreover, even for map entries which 
are isolated but not lost, it would be helpful if their elimina- 
tion from the map was automatic,' since it may be some time before 
they are exercised. This can be accomplished by adding to the 
base-level system a relatively simple operation of the form: 

exerqlae (J) 

which simply exercises the I-th map entry by reconstructing its 
capability. A low-priority background process (sometimes called a 
"daemon" or "phantom") can now be constructed which uses the new 
operation to slowly sweep through the map eliminating isolated map 
entries. The rate at which this Is done is a tradeoff between 
minimizing the extra load imposed on the map machinery and maxi- 
mizing the rate at which map space is recovered. Given generous 
allocations of map space to the various accounts, the rate could 
probably be quite low. The exercise operation is not available 
to the users, since they have no use for it, but it is not at all 
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dangerous, hence the background process need not be trusted by 
the base level system. 



3.8 Possible Elaborations on the Design 

There are several directions in which NCS as described in 
this chapter could be elaborated. We here digress briefly to dis- 
cuss four examples, arranged in order of increasing difficulty 
of adding them to the implementation described. 

A simple feature which might well be included in an actual 
system allows examination of the relationship of two capabilities, 
to determine if one is a descendant of the other in the same map 
tree. This would be useful: 

a) To determine revocability of one capability by another. 

b) To determine accountability for unauthorized distribu- 
tion of a capability. 

This checking could easily be provided by an operation which simply 
scanned from the first capability's map entry to the root (base- 
level object) entry of the tree, watching for the second capability's 
map entry. 

Another feature, which has been mentioned previously, would 
be the definition of other useful kinds of boxes in which to seal 
capabilities. For example, a box in which two or more capabilities 
could be sealed would eliminate the need for a small segment to 
act as the root of a compound representation of an extended object. 
This is similar to the scheme used in the HYDRA system [Wu 74] . 
On the other hand, its implementation would require variable-sized 
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map entries, thus significantly complicating the implementation of 
the map. 

A third rather interesting possibility is based on the obser- 
vation that the masking of privileges by the revoke operation is 
not an intrinsically irreversible process. One could just as easily 
provide an "unrevoke" operation for restoring previously revoked 
privileges. Note that in this context, the use of locker boxes 
takes on a new significance, since it not only prevents inter-user 
interference, but also prevents the possessor of a capability from 
restoring privileges which have been revoked from it. The only 
major implementation difficulty with this feature is the impossi- 
bility of automatically deleting totally revoked entries from the 
map, since they may later have their privileges restored. This 
would require explicit deletions of map entries, making the appear- 
ance of the mechanism more complex. In addition, the whole notion 
of unrevoking privileges cannot be described cleanly in terms of 
the family tree model. Nevertheless, this feature could be quite 
useful, since it allows increased levels of trust between domains 
without necessitating the inconvenient repetition of the capability 
distribution procedure. The whole notion of temporary revocation 
could be quite useful, for example, in the debugging of locking 
protocols in a complex multi-process data-base system. 

The fourth possibility is similar to the previous one in the 
sense that it attempts to preserve an established pattern of dis- 
tributed capabilities while changing the meaning of those capabil- 
ities. In this case, the change is to allow switching of the con- 
tents of an extender box. This would enable a layer implementing 
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an extended object to dynamically change the identity of its repre- 
sentation. Of course, care must be taken to avoid the possibility 
of circularities in the map; this can easily be done by using the 
first extension mentioned above to detect the case in which the 
new representation is a descendant of the extender which is being 
modified and signal an error. 

The extensions described in this section could be added to 
NCS without excessive difficulty, but for the sake of clarity, the 
remainder of this thesis will assume that only the mechanisms ori- 
ginally described in Section 3.4 are provided. The facilities 
described in Chapter 4 would require some modification if any or 
all of the extensions were in fact included. 
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. Chapter 4 
Two Facilities Using the New Capability System 

4.1 Possible Facilities Using Generalized Sealing 

The purpose of this chapter is to briefly explore two examples 
of helpful facilities which can be constructed using the NCS 
generalized sealing mechanism described im Chapter 5. (tee is an 
improvement to the base-level domain-call machinery providing 
selective revocation of capability parameters passed on a call 
when the corresponding return occurs. ; the other is *» extension 
providing a new type of object called a directory* which tallows 
storage and distribution of capabilities in a manner which is often 
much more convenient than that provided by the base-level system. 

Other useful facilities could alao be def faied^ in a similar 
fashion.. Plausible examples might include: 

a) An interprocess communication facility providing extended 
objects called message channel*, capable of transmitting 
messages containing capabilities valid only until the 
next message Is received. 

b) A rental mediation service, guaranteeing to the lessor 
that privileges will be revoked upon contract expiration, 
and to the leseee that revocation eannot occur before 

• that time.: 
These and other possibilities will be left unexplored here. The 
point is simply that the nested capability scheme allows the 
construction of an open-ended set of extensions* many of which can 
alao make use of the revocation properties provided . 
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4.2 Revocable Parameters 

There are certain events which constitute natural points at 
which to distribute and revoke capabilities . The most obvious 
examples ace the occurrence of a domain-call and the subsequent 
corresponding return. As discussed by Schroeder fSe 72] , the 
temporary granting of access tn parameter objects is a natural 
and useful feature of calls be t w e e n mutually suspicious domains. 
There are other situations, however, in which it is unnecessary 
or even inappropriate to revoke all capability parameters when a 
return occurs. In particular, as previously noted* •■ calls ■ to trusted 
machiae~ext*asion domains need not revoke their parameters, which 
can result in substantial savings. He therefore propose a more 
general mechanism in which the caller can specify, for each para- 
meter passed, whether it is to be revoked when the called domain 
returns. 

It would probably be possible te provide this improved domain 
call as an extension rather than as integral pert of the base- 
level system. This would require that all domain-calls and returns 
(or at least all these which involved any revocable capability 
parameters) be routed through this extension, which would be both 
clumsy and costly, lie therefore describe revocable parameters as 
being included in the base-level domain^call mechanism. 

In the previous discussion of parameter passing in Chapter 2, 
we found it unnecessary to specify the details of the copying of 
capabilities from the caller's address space to the callee's 
address apace. In discussing the modifications necessary to pro- 
vide revocable parameters, we continue in the same fashion, 
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describing the implementation, of parameter passing in terms of the 
get_parameter and put_parameter operations used in the discussion 
of TCS in Section 2.2. 

When a domain call occurs, the caller controls parameter , 
revocation by passing a Boolean. vector R as an extra parameter, 
each element of which specif iep whether the corresponding parameter 
should be revoked upon -return;! The call thus has the form: 



Call (C G ,|> r i> 2 ,...,P n ,R) 



where R[i] controls the revocation of P.. 

Revocation of parameters is implemented using the same push- 
down stack which saves the return gate used to reactivate the call- 
ing domain when the callee returns. Thus, instead of just a gate 
capability, each domain-call corresponds to a packet of information 
as shown in Figure 4.2-1. The first item is N_, which is the 
number of capability parameters to be revoked, and the last item 
is the return gate. Between them are the N_ capabilities which 
will be revoked when the return occurs. Figure 4.2-2 depicts the 
domain-call operation, and resembles Figure 2.2-2 which shows the 
TCS version. The differences comprise the steps necessary to save 
the extra information in the stack. Each revocable capability 
parameter is sealed in a revoker box; one copy of the sealed capa- 
bility C is passed to the callee, and another is retained in the 
stack. The discipline followed is thus that of Figure 3.5-2; seal- 
ing of the callee' s parameter in a locker is not necessary, since 
it is not received by any other domain. Figure 4.2-3 depicts the 
domain-return operation, as compared with the TCS version in 
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call(C G ,P lf P 2 P N _ 1§ R) 
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Figure 4.2-2: NCS domain-call operation 
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return ( ) 



[ ENTER ) 
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N R + pop( ) 
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C «- pop( ) 

revoke (C,0) 
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G <- pop( ) 
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Figure 4.2-3: NCS domain-return operation 
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Figure 2.2-3. The added steps use the information in the stack to 
revoke the appropriate capabilities from the callee before retriev- 
ing the return gate and returning control to the caller. Note that 
the revocation is total, and thus releases map entries in an orderly 
way, as discussed in Section 3.7. 



4.3 Directories 

The notion of a directory , catalogue, or name-table mapping 
symbolic object names into some form of internal object pointer 
has appeared in most operating systems. The idea of a large 
collection of directories arranged in a tree-structured hierarchy 
originated mainly with the Multics system [Da 65], and has been 
adopted in several other systems £nce that time [St 73, Co 72, 
Ri 74]. 

A directory consists of a variable number of entries, each 
containing a different symbolic name and a pointer to an object 
(plus other information to be discussed shortly). The assumption 
that a unique directory entry is created with each object, com- 
bined with the fact that directories are themselves objects, induces 
a tree-structured hierarchy on the set of all objects in existence 
at any time. The internal nodes are the directories and the leaves 
are the objects of other types. Concatenating the names of all 
entries along the path from the root directory to a given object 
yields the tree name of that object which uniquely identifies it. 

The global tree-structured view of the universe of objects 
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can be useful In several contexts, such as system backup and 
recovery, accounting, and, as described below, in solving the 
"lost object problem," but it is often more convenient in other 
contexts to modify this view in two ways: 

a) To allow the establishing of several directory entries 
for the same object. 

b) -To allow general path names which can be interpreted as 

starting in any directory, rather than only the root- 
directory. 
Both of these features can be added without disturbing the under- 
lying tree-structure, as long as the extra entries ( "links" ) in 
(a) can be distinguished from the original entries ( "branches" ) 
when this is desired. This treatment of links as being full- 
fledged directory entries, contrasts with the Multlcs approach 
in which links are merely a re-naming device and have no pro- 
tection significance. We choose this approach to facilitate sub- 
letting of rented objects. 

In addition to naming, the directory system is useful for 
purposes of access control. Attaching an access list to each 
directory entry aids in the orderly distribution of privileges 
to access shared objects. Each entry in the access list contains 
a pair 

(lock, privileges) 

which allows any possessor of a key matching the lock to obtain 
the corresponding privileges. (Of course, the specification of 
the access list, like the creation and deletion of entries, 
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represents an access to the directory itself, and must also be 
controlled.) The simplest example of a lock would be a user name. 
A more sophisticated version of this is the "principle identifier" 
used in Multics [Sa 74], which is a kind of three-dimensional user 
name with more complicated rules for matching locks with keys. 
An even more flexible scheme will be described below. Note that 
in all such schemes, a user may not invent his own key(s) , but 
may invent any locks he chooses and apply them to his objects, as 
discussed by Lamp son [La 69] . 

In non-capability-based systems, directories are usually 
implemented as base-level objects [Or 72, Ri 74], since their 
access lists are generally used as the system's primary protection 
facility. In a Capability-based system, however, directories can 
be Implemented as a higher-level extension, providing symbolically 
named "pigeon holes" for the storage and dissemination of capa- 
bilities [Fa 68]. This is an attractive organization, since it 
removes from the base-level system all handling of symbolic names 
and the corresponding variable-sized data structures. From the 
point of view of the base-level system, the directory layer is 
simply another user domain, although, of course, it must be regarded 
as a trusted machine extension by normal user programs which store 
their capabilities in directories. The desirability of providing 
both directories and capabilities in the same system is convincingly 
argued by Lampson [La 69] . 

The directory layer described below provides for storage of 
any number of capabilities in each directory, one per entry. 
Attached to each entry is an access list authorizing a domain to 
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obtain a sealed copy of the stored capability by executing 

* 



C ■*■ lookup (Cp, Name, C R ) 



where C_ is a capability for the directory (authorizing lookup 
access), Name is a character string, and <L. is a ke y capability. 
The unique ID of the key capability is matched against the locks 
in the access list of the entry and the corresponding privileges 
are returned in C . Subsequent reduction of the privileges 
authorized to holders of key G will retroactively reduce the 
privileges in C, using the underlying revocation machinery. 
(Various conditions, such as failure to find an entry with the 
given name, or failure to find a lock in the access list which 
matches the key C v cause errors to be signalled and no capability 
to be returned.) The use of freely distributable capabilities as 
the keys authorizing directory lookups allows the users to flexibly 
and economically establish any group authorisation scheme desired 
by simply passing keys to each other. Heither the base-level 
system nor the directory layer need take any explicit notice of 
such groups tLa 69, St 73] . More complicated facilities such as 
path name lookup [Da 65], multiple directory searching [Or 72, St 73] 
and automatic lookup on first use of a symbolic name [Da 68] 
could be implemented in terms of this basic lookup primitive; 
these will not be discussed here. 

In such a directory system, there is no intrinsic distinction 
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* 
In terms of base-level operations , this would be written 

C «- call (Cg.Cjj.ltame.C^) 

where C_ is a capability lor a gate into the directory layer 
corresponding to the lookup operation. 
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between the various directory entries containing capabilities for 
a given object. For the reasons cited previously, however, it is 
useful to distinguish one of the entries as a branch and consider 
the others to be links. In particular, one can solve the lost 
object problem by guaranteeing that the branch exists for at least 
as long as the object. This i# accomplished by creating the 
object and the branch simultaneously, and having the directory 
system, upon removing the branch from the directory, delete the 
object (if it still exists). 

The use of branches to solve the lost object problem is rela- 
tively straightforward in the case of base-level objects and 
directories. By performing the creation of all such objects through 
calls on the directory layer which also create a directory branch, 
one can insure the existence of a branch for each new object. 
When the branch is removed, the object can be destroyed by the 
directory layer, either internally < in the ^case of directories) or 
by calling the appropriate operation (M: the eiffle* of base-level 
objects). 

In the case of extended objects, however, the situation is 
more complicated, for two reasons: 

a) It is inappropriate |or £$£. directory, lay^r tq have 
embedded in it any knowledge of, (e.g^,, calls on) higher 
layers.. ,, v , ,..„, =.. ,..,.,' 

b) New higher level extended types can, be defined at any 

time. ..-..; 
These considerations render impossible the, erea^ionrpf such objects 
via the directory layer, and necessitate a more circumspect 



148 



approach to their deletion when a branch is removed. 

When a higher layer creates an extended object X and wishes 
to take advantage of the directory system to keep X from becoming 
lost, it can do so by executing 



makej>ranch (C^, Nsna, C^, G^) 



This creates an entry in the directory indicated by C_. The 
entry has name Name and contains C_, a capability for the new 
object. In addition, the entry holds C_, a capability for gate 
G into the caller (i.e. the layer Implementing the object). When 
the branch is later removed from the directory, the directory sys- 
tem guarantees to execute 



call <C G ,C X ) 



The gate G should correspond to the deletion operation for objects 
of the extended type, hence this is equivalent to 



delete (O 



Of course, it is the responsibility of the larjrer implementing X 
to insure that this call does in fact result in the deletion of X. 
The directory layer's only concern is that It must be prepared for 

anything which may happen between the time it performs the call 

_ _: H , 

Repeated use of the makejbrsnch operation specifying the same 
object X would cause the directory structure to fail to be a 
tree. This might be of concern to layers *t or above the level 
at which X was implemented (although it certainly would cause no 
trouble for -the directory 'layer^ : ^\ ;, 1^ ; ia^^ v li^^sWiifci^ the ob- 
ject could protect itself from this situation if/ the mskejbranch 
operation were modified to require an 'WttSfr parameter Cj, a 
capability for the type of X, as authorisation to make a branch 
for X. 
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and the time the callee returns. This could include various types 
of errors, blocking of the process, and even further calls on the 
directory layer. The straightforward way to handle this is simply 
to have the directory layer complete its part of the branch removal 
and then exit to the object deletion operation via a jump-call as 
described in Section 2.2. 

It might appear that the calling of the higher layer object 
deletion operation by the directory layer violates the ordering 
constraints of layered system construction. This is not really 
the case, however, since this call does not represent any knowledge 
of the higher layer embedded in the directory layer. Such "blind" 
upward calls are quite similar to hardware "traps" or "exceptions." 

The other directory layer operations of interest are: 

makelink (Cj^Hame.C^) 
removeentry (C_,Name) 
setJLock (Cjj»M«a»,I*,P) 
C_ *■ createjfcey ( ) 
create_directory (C_,Name) 
deletedirectory (Cp) 

The make link operation establishes a new entry in directory D, 
containing C and named Name.. The removejentry operation 
removes a link or a branch. In the latter case, it performs 
object destruction as described above. The setJLock operation 
establishes a new lock on the named entry in directory D. The 
lock is L (i.e. it can be opened using a key with capability-ID - L) 
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We ignore the extra complications involved if object deletion is 
allowed to fail. 
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and it confers the set of privileges F. The create_key opera- 
tion simply returns a capability of type 'key' with a new unique 
capability- ID. The createjdirectory operation establishes a new 
empty directory as a son of directory D (i.e. pointed to by a 
new branch in D with name Nana). The deletejdirectory opera- 
tion deletes the directory D. This requires removal of all 

... » 

entries from D t including any branches for other directories 
which must thus be deleted, and so on. In other words, the entire 
subtree rooted in D must be traversed and delated. This compli- 
cation is best postponed until a higher level utility program, 
hence the directory layer can simply refuse to delete a non- 
empty directory. 

The implementation of directories as described is relatively 
straightforward. Each directory is represented as a segment, con- 
taining entries formatted as in Figure 4.3-1. The original capa- 
bility C and the entry name are present when the entry is first 
created, along with the deletion-gate capability in the case of a 
branch. Subsequent use of the set_lock operation proceeds as 
shown in Figure 4.3-2. First the leek is added to the access list 
if not already present , together with a capability to hold the 
privileges corresponding to the lock. This capability is created 
by sealing the original capability C„ in a revoker box. Then 
the privileges in the capability are revoked down to the desired 
level. Mote that in the case of applying the setJLock operation 
to an already existing lock, any outstanding capabilities previously 
obtained via that lock using the lookup operation will also have 
their privileges revoked. Finally, if the revocation was total 
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set_lock(C ,Name,I*,P) 
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Figure 4.3-2: The setJLock operation 
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(i.e. P = 0), the lock is deleted from the access list. (Such 
total revocation is also performed on each lock in the access list 
when the entire directory entry is removed. This is another exam- 
pie of orderly use of the underlying map mj*china%$ 'al discussed 

inaction 3liff" ■ ' : ->'-' ■---*•*■<-> ' '- *• "••:>■,-!. -. 
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Chapter 5 
Summary and Concilia ions 

5.1 Summary 

This thesis has discussed integrated naming and protection 
mechanisms for computer systems, providing protected names called 
capabilities which both identify; an object and authorize access 
to it. A major advantage of capabilities is the flexibility pro- 
vided by their being freely copyable. A corresponding disadvantage 
in existing capability systems has been the .difficulty of revoking 
previously distributed capabilities. .The mi^ result of this 
thesis has been the design of a capability system providing both 
free distribution and orderly revocation of capabilities . Various 
approaches to this problem were discussed in Chapter 2, culminating 
in a set of goals to be met by a new design. The generalized 
capability sealing mechanism of Chapter 3 was shown tQ meet these 
goals, providing selective revocation of capabilities, as well as 
a flexible type extension facility. A possible implementation of 
the design was discussed in sufficient detail to demonstrate its 
practicality. Various possible elaborations on the design were 
also discussed. Chapter 4 described, two |acili,|ies ajjplylhg 
revocable capabilities to the needs of users in specific ways. 



5.2 An Area for Further Research 
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In terms of the facilities provided, the naming and protection 
mechanisms described in this thesis appear to be a sound basis 
upon which to build a secure and flexible user environment • In 
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particular, the provision of revocable capabilities eliminates 
one of the main objections often made to capability-based designs 
[Sc 72], thus making the proposed design applicable in a wider 
class of situations. One could thus characterize the thrust of 
this thesis as an attack on the flexibility aspect of the pro- 
tection problem, 

On the other hand, the thesis does not make any direct attack 
on another more general aspect of the protection problem which one 
might call the comprehensibjlity of protection mechanisms. 
Experience indicates that protection mechanisms which are confusing 
to users are likely to be misused, or even go unused [Sa 74, sc 72]. 
Even the usef who correctly applies a confusing protection feature 
may feel no great confidence that it enforces his intentions. 
There are at least three ways in which protection systems can be 
confusing: 

a) They can be based on a disorderly set of separate but 
interacting mechanisms. 

b) The relevance of the mechanisms to specific situations 
can be obscure. 

c) The correspondence between global state of the protection 

machinery and the desires of the users can be difficult 

■'■.:,• .'■■•■ ■-' -",..-. ; ' •: ' J* 'ic 

to assess. 
A fair amount of progress has been made on problem (a) ■ The 
early proliferation of ad hoc protection mechanisms was a major 
motivation for the original development of capabilities [DVH 66] , 
as well as later more abstract treatments by Laapson [La 71], 
Jones [Jo 73], and others. On the other hand, strict minimization 
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of the set of primitives will not necessarily clarify the descrip- 
tion, especially since it say exacerbate problem (b). For example, 
our unification of privilege revocation and type extension in a 
single mechanism, while interesting in itself, may or may not repre- 
sent a net increase in the comprehensibility of the design. 

Problem (b) is caused by the gap ~ often quite broad — 
between the concerns of the human users and the mechanisms provided 
by the protection system, in terms of which they must express 
those concerns. Of course, the user heed not deal only with the 
protection primitives of the system; various extensions, such as 
those mentioned in Chapter 4, can be provided. These do not go far, 
however, in attempting to capture the interactions between users 
seen in the larger social context, this is due in part to the 
imprecision of many legal and social principles, resulting from 
their Implicit reliance on the reasonable judgement of the parties 
involved, a characteristic sadly lacking, in most computers. Much 
work remains to be done in mapping Such principles into the pro- 
tection primitives of computer systems (So 74, Pe 74, tu 74]. 

Problem (c) is perhaps the most difficult of the three. 
During our discussion of capability mechanisms, we emphasized 
the desirability of allowing distribution and revocation of capa- 
bilities without requiring global knowledge of such propagation on 
the part Of the participants. Such global knowledge is sometimes 
desirable for its own sake, however. Moreover, even if the entire , 
state of the protection machinery is visible (which can itself 
raise serious questions of privacy) , the full significance of that 
state cannot be assessed without knowledge of the levels of trust 
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and suspicion between the various possessors of access privileges. 
This appears to be a very fundamental problem, and it is not clear 



what approach (If any) will prove fruitful in dealing with it. 



5 . 3 The Fut ure of Protection 

Much work remains to be done in the area of protection. In 
the long run , protection will contribute to the development of 
generally available computer utilities in at least three ways: 

a) By facilitating the development of extremely large soft- 
ware systems, such a* sophisticated service programs, 
and the operating sys*e*«fc f the computer utility itself. 

b) By protecting the investments of users who develop large 
proprietary programs and /or* data bases, thus providing a 
suitable marketplace for such services. 

c) By enforcing social Hi*Ott*^I#%n the dissemination of 
stored information. 

Given the difficulty and importance of the probifems to be solved 
protection premisses to be an active Jtftea of research for many 
years to come. 
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